Wednesday, March 25, 2015

dp vs. ppi vs. dpi vs. px

     I was developing layouts for the app I am working on and I discovered that I needed to make different layout xmls (Extensible Markup Language) for phones, tablets, and large sized tablets as well as landscape views for all of those layouts. Originally, I used normal, large, and xlarge qualifiers when creating the layouts but I discovered a problem.

A large layout on one tablet looks completely different than that of another.

     A Samsung Galaxy Tab S 8.4 and a Nexus 7 are both considered large layouts, but when I developed the large layout, I used my Galaxy Tab as an emulator. Thinking Yay! I can finally upload this to github! (My first "real" commit). After making a pull request to my collaborator (Great Team Leader Joye), I got an email that said this:


Hey Gabrielle!
I was excited to see that [the layout] flips on my device! Here are some screenshots of some of the flipped layouts. As you can see, a few of them need a little bit of adjusting. Also, the Report Settings screen always crashes when it is in the horizontal orientation. I'm not sure why. Perhaps just one of those weird null pointers.
But, also attached is the APK! Try it out and let me know how it goes for you!
Joye 








     I was so disappointed when I got this email, but it was extremely useful! This made me realize the problem at hand. Layouts should be more than just size ("large") specific. I needed to figure out a way to make them specific to the device itself. I found two qualifiers called "Screen Width" and "Screen Height." So I thought okay, let me go find the dimensions of devices that give trouble. This is where the "dp vs. ppi vs. dpi vs. px" comes in. I assumed it wanted those dimensions in inches. Wrong. Android uses an acronym called "dp" for a good many of their properties. Margins use dp and so does  padding, height, and width use for widgets. I discovered this the first time I started using the ADT (Android Developer Tools) bundle with Eclipse, but I really didn't think much about it and just figured out how to use it. Okay, realistically, I always used the "guess and check method." That strategy they taught everyone in 3rd grade for math? Yeah that's the one. Being the ignorant self I can occasionally be, I needed to figure out what dp was and how it related to the size of devices. Dp stands for density pixel. It was also known as dip at one time (Density-Independent Pixel). This is what Android says is needed when defining UI layouts and to express layout dimensions or position because it is more accurate than an inch or a pixel because it does not vary in units and it is not the same physical size on every screen. This means that it is proportional to the screen.

But how do I find what dp I need for my device? It's an 8.4 inch and Android says I shouldn't use inches to define size in layouts because it's unreliable?

     This is the hard part. After researching my tablet (the galaxy tab), I found out it is 2560 x 1600px (pixels) and has 360 ppi (points per inch). I didn't find the dpi (dots per inch) and of course I didn't find the dp because that would just be too easy. So I thought maybe I can find a conversion calculator online! Nope. Also I found this page that will help and be more specific (also my source): Difference between px, dp, dip and sp in Android. I never got a clear idea on how to convert these things so I decided to step back and take another approach. Maybe I shouldn't use those qualifiers and look into grid layouts instead of relative layouts?



--------------------------------------------------------------------------------------------------------------------------



     Remember how I was talking about another IDE for developing for Android? Yeah? Well listen to this. It is very important. Do not use the ADT bundle with Eclipse! I repeat, don't even try to use it. It makes you hate developing for Android through all of the crashes and problems it creates. The build time takes forever and also the emulator even if you have haxm (Intel's Hardware Accelerated Execution Manager) installed. Also I think it might discriminate against girl developers (joking here). I was one of two girls in my Android Development class of 19 and it wouldn't even let me make one change before crashing. Just don't even waste your time even if you have experience with Eclipse.

Here's an excerpt from an article that I found when debating Apple and iOS. In one part, it basically just makes fun of the ADT bundle with Eclipse.


Oh, Android. The current statue-of-the-art IDE is Eclipse, customized with Android plugins, and it is embarrassingly bad Slow, clunky, counterintuitive when not outright baffling, poorly laid out, needlessly complex, its just a mess. Its debugger is so clumsy that I find myself doing log-file debugging most of the time, whereas the XCode debugger is my iOS go-to bug-hunt tool. And the less said about the Android emulator, which takes minutes to launch and then half the time fails to connect to the Android Debug Bridge, the better. Now, to be fair, Google knows this is a problem, and they are working on a new Android Studio IDE. It's nice to see they're working on it, but it's amazing - in a bad way - that 4.5 years after I purchase my first Android phone, this mess is still the state of the art. 

 Android vs. iOS Development: Fight! | TechCrunch


Now this post was written in November of 2013 so I'm sure he (Jon Evans) is very pleased now!


You can see more about my adventures with layouts and learn how to create them here.