This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
How dificult is to develop an Android application to be used both mobile phones and tablets? Perhaps it is a fool question, but I don't know if you, as a developer, have to be in mind some consideration about it.
Any correction of my English will be gratefully accepted.
Your English is far better than mine. I am glad there is a whole bunch of editors that correct me before it gets into the book.
Dave is probably a better expert at this. He will probably address this tonight.
The android deveoper site I believe has a couple of articles on how one can use "fragments" to develop applications for varying screen sizes. However the fragments library is not there for phones yet. Although there is a back port of fragments for 2.3 I am not sure how compatible that is with the 3.x api.
Having said that, most of the non-ui stuff should work well for both phones and tablets. I suspect that due to screend size differences you may want to develop two applications by following a common services layer. You can make it work for both if are careful and make comprimizes. But I am not sure if you will get the optimal experience.
I hope that it let us (developers) to generate an unique UI to an application without considering where it will be executed. In other case, the effort to generate two diferents client layers probably obligue you to decide which device is the development over and, if you decide to perform that, it'll increase the maintenance efforts.
About the business layer, I'm agree with you. If the double UI is necessary, perhaps an unique business layer won't be the optimal solution.
Thank you again!
Joined: May 11, 2011
the API will work in both tablets and phones as long as you are able to take into account the screen sizes and make it behave differently. So on a case by case basis you may be able to write once for both.
But I suspect that it is conceptually difficult to satisfy both clients with a single UI unless the UI is a bit simplistic
This is a touchy subject. In theory, a well-behaved app developed for a phone will run on a tablet, but you might see it centered with big black bars around it since it doesn't make sense to spread a small UI across a tablet's screen. So while it works, it's probably not what you would prefer. So now you're developing a version of your app for the tablet. You could use a custom layout for the xlarge screen size, but this is not what Google recommends. Besides, with all that extra screen real estate, you're probably going to want a different type of functionality anyway. Instead of displaying a list of items by itself, and displaying the details of that item in a new activity when you click on one, the tablet display allows you to display the list to the side, and display the details at the same time to the right. Fragments are intended to be the way to do this. One way to think about fragments are like sub-activities. In some ways, you encapsulate the behavior of part of the screen as if it were its own activity, but in fact they are fragments. Fragments work together on the screen in a single activity. It's difficult to explain them well in a post (we devoted a whole chapter to fragments!), so I want to also attempt to answer the other aspect of your question.
Trying to use fragments in older (pre-3.0) versions of Android is problematic. Yes Google released a fragment SDK that works back to version 1.6. BUT! It's buggy. And it doesn't include a fragment-ized version of MapActivity so you can't do maps using it. You'll need to implement different activities anyways for the older releases of your app so I just don't see that you're any better off. My advice is to try to share as much application logic classes between a phone version of your app and a tablet version, but only use fragments on the tablet side.