Develop Reference

Android Migrating from phone app to tablet

I've developed an android phone app in which the navigation is mostly activities and starting activities for results. I've read that in order to make the tablet layout look like 2 screens of my phone app one next to the other I should have made it with fragments. Is there another way to migrate my functionality to the tablet app? Meaning to keep the start activity for result but just concatenate two activities on screen? (it may sound stupid, I know). Thanks

In order to keep the software design simple and modular, fragments come in really handy. You can use the same fragment's UI design + working code in multiple places without changing much functionality.
Since you have the code built and running in terms of activities, it won't take much time to migrate/port it to a Fragment since the life cycle methods are pretty similar. All you need to do is study the life cycle of a Fragment and move code chunks from the Activity to the Fragment class.
You can study all about Fragments here - http://developer.android.com/guide/components/fragments.html
or maybe a training session here will help you more -
http://developer.android.com/training/basics/fragments/index.html
You will learn a lot and once you have tried it you will be able to comprehend the advantages in a much better way. In future always make it a point to design in terms of Fragments to have a much modular design.
Along with that I think you will also need to learn to design layout for multiple screen sizes. This link over here will help you understand how to support multiple screen sizes -
http://developer.android.com/guide/practices/screens_support.html
If a tutorial to do this very quickly is what you seek then this should help -
http://www.101apps.co.za/index.php/articles/converting-android-activities-to-fragments.html
All the best :)

It very depends on your app GUI structure. Sometimes, you even not need to adapt your GUI for tablet (if you build interface dynamically basing on screen dimension). As rule, if you have two screens where one screen is advanced or logical extension of other then you can union it into one screen on tablets for better informativeness. Secondary way, as rule, based on fragments.

You can achieve it with help of Activity group but it is deprecated in Api level 13, for more details please visit http://developer.android.com/reference/android/app/ActivityGroup.html, but I will suggest to go with Fragment as Fragment having nearly similar life cycle like as Activity with extra methods and features. Please refer link for more details http://developer.android.com/guide/components/fragments.html

Two activities or two fragments?

In an Android app, I have two screens* the user sees, one for preparing a query and the other for displaying the results. The right UI here is to have the query preparation in one screen, and then see the result on the second screen. Since this app is aimed at phone users, there's no need to display the two at once.
The traditional Android way is to use two activities, a QueryPreparationActivity and a DisplayResultActivity, and switch between the two. However, I've been hearing more and more about how the Android UI is switching to fragments. I can implement the two screens as two fragments and have the activity switch them, but is it worth the trouble? I will essentially be reproducing the Activity management code Android already has.
Is there a reason to use two fragments here?
*I'm using the term screen, because it isn't necessarily an activity...

Personally, I always develop using Fragments.
But the best reason I can give you for using Fragments is when you develop for handset and tablet devices you get a lot of reusability.
I know you already mentioned that there is no need to show both screens at once. But say later you were to develop the same "screen" for a tablet device and realize that the preparation screen is too barren and want to have both queryprep and display result show at the same time, you would have to write a totally new 3rd activity.
If you used fragments, you would reuse your 1 activity and 2 fragments, and that activity should be coded smart enough to determine the size of the screen and show the proper layout.
Code Reusability & Flexibility are the buzz words here.
If you have any questions please leave a comment and I will expand my answer. If you like my answer, please upvote and accept.

Fragments were introduced encapsulate UI elements and related behaviour into a single, reusable module. Before fragments you had to re-write the much of the same code that 2 or more activities had in common especially if you couldn't find a good approach to abstract the UI/control code into a super class. This was further complicated by the limitations that activities only call setContentView once. So sharing some code between activities wasn't all that nice.
Now, to answer your question, it all depends on you. If you think that further down the road you could use the QueryPreparation or DisplayResult ui as a module (layout and logic behind it) then go for the fragment implementation. It could be a different layout for landscape view on phone or if you decide to support smaller tablets like the nexus 7. If you are sure that it will never happen then stick with activities. Personally, I use fragments everywhere and they are a sure way to "future proof" your implementation for reuse down the road.

In short Fragments were introduced to accommodate the emergence of tablet/large screen devices and allow developers to create applications that will run across a wide range of screen sizes with very little change to code.
More can be read here at the Android Blog. That blog also details some of the finer technical details for the reasons for the move toward Fragments. Also introduced at Goolge IO 2012 were DialogFragments which you should consider using instead of Dialogs. Another blog post here describes them.
You're better off getting used to using Fragments and DialogFragments from the get go as this is the way Android is moving. Only use individual Activities if you really really need to do a quick-and-dirty app for say testing purposes. Fragments, in my opinion, do require a bit more code-work to incorporate and to initially get your head round but it's worth the effort.

Performance of multiple MapFragments (Android Map API v2)

I searched the docs of the new Google Android Map API v2, but didn't find anything about it. Before v2 we (officially) couldn't properly display more than one map per application (process). I assume that with MapFragment implementation it's no longer an issue. I also know, that Fragments can be self-contained since API 17. And, last but not least, there is compatibility package, which makes it possible to port it all back to at least API 8 (in API 7, there's no OpenGL 2.0 so the maps wouldn't work afaik).
Sa I have all the ingredients to port my app to Maps API v2 and implement the following scenario: ViewPager contains Fragments and each of them contains a MapFragment.
But should I do it? I mean, would I face performance issues if I had e.g. 20 Fragments containing MapFragments in a ViewPager?
If you found anything that addresses my concern in the docs or somewhere else, please tell me.
EDIT: Example usage: Let's imagine a screen containing informations about some specific item - place, event, article. Also let's imagine that, among other informations, it must contain a map to be fully functional. But I would like the user to be able to swipe to another item if he wants. Each item has its own map.
Side note: I know that I can implement one map outside the ViewPager and just update it based on the currently displayed item, but it's not what I'm looking for - it's not user-centered design.
Possible solution (but not checked yet). ViewPager only keeps a few (default - 3) Fragments in it's cache and recreates them when they're about to show up, so there won't be much memory overhead as only a few MapFragments are needed. The performance problem may be the MapFragment inflation which is quite heavy, I believe - but that can be solved with recycling of MapFragments.
So why won't I implement it if I believe it will work nice? There's another problem which makes it impossible to move MapFragments without the app look like it's broken. See this.

You could easily test it but my guess is that it would very much depend on the phone as Maps still is fairly heavy to run.
That said I'd never recommend this kind of user navigation. A map can already be swiped at so why would you add ViewPager swipe as well? This would make a very confusing user experience. If you want to switch between different views/point of interests you should add buttons (overflow menu buttons preferred as in the navigation app) or something similar that helps the user navigate around.

Yes, you definitely would run into performance issues because ViewPager doesn't employ view recycling by default; you can even bloat it with ImageViews let alone MapFragments.
As far as caching and recreating fragments in ViewPager - there's a HorizontalListView lib that'd probably save you the effort as it does support view recycling.

Is it advised to build all apps using fragments?

In the modern Android development, is it advised to completely move onto fragment-like development?
To build both mobile phones and tablets apps using fragments and not do differentiate between activity-solely and activity+fragment apps?
Are there any Google Android Team's official recommendation to completely move to "fragments" or not to completely move?

You don't have to develop using fragments but if you want to provide the maximum number of consumers/devices with the best possible environment then you should switch to fragments. However if you really think fragments are the devils work you can stick to just Activity-based development and provide a sloppy looking UI.
As far as Googles' feelings go, I think this sums it up-
Embedded Activities via ActivityGroup were a nice idea, but have always been difficult to deal with since Activity is designed to be an independent self-contained component instead of closely interacting with other activities. The Fragment API is a much better solution for this, and should be considered as a replacement for embedded activities.
For more info about fragment usage check it out here and for more of the design philosophy check out this post.

Single Activity Application

I will try to keep this short, but I need some advice.
I work on a team that is developing applications for android, iphone, and wp7 in parallel.
We have a design team that comes up with a single design for all three platforms.
The latest application’s design is more marketing than productivity. The original POC for this app was done on the iphone. The design is very animation centric and most state changes are seamless (things will animate on and off the screen during state transitions).
If I keep developing against this design it means I will have to have everything in a single activity. So far, this has been a major headache. To my knowledge, dividing your application into activities is almost required. I could try to dynamically load and unload views as I change states but this doesn’t seem right.
I see where the design team is coming from where they want all these state changes to be seamless, but I don’t think this is right for android.
I would like to know what makes most sense. Should the design change to incorporate multiple activities or would it be worth trying to make this work.

We have a design team that comes up with a single design for all three platforms.
That's akin to coming up with a single floor plan to be applied to apartments, single family homes, and warehouses. The designers, or management, need to have their heads examined.
The latest application’s design is more marketing than productivity.
Did I mention that the designers, or management, need to have their heads examined?
If I keep developing against this design it means I will have to have everything in a single activity.
If I am interpreting your requirements correctly, that is probably accurate. While you can arrange for animations between activities, it is more of a "slide the old off, slide the new on", and I suspect that your requirements exceed that.
To my knowledge, dividing your application into activities is almost required.
It is certainly Android's intended development model for ordinary apps. However, games and the like may not follow this pattern, and you don't have to either.
I could try to dynamically load and unload views as I change states but this doesn’t seem right.
Depending on how many states there are, you might just hang onto all of them, recycling as you go.

I am surprised no one mentioned fragments which can be used instead of activities at many places.
Fragments can be seamlessly animated in and out or an activity.

You might want to take a look at subclassing ActivityGroup for your top-level activity. That can host multiple sub-activities. TabActivity, the only stock subclass of ActivityGroup, is perhaps not what you need because it includes a tab widget, but you can use it as inspiration for what you do need.
What specific headaches are you having with a single-activity architecture? Perhaps there are ways to make that less painful.

In general, if you are aiming to have native apps with a native look and feel, it is not reasonable to have a single UI design for all three platforms. The UI guidelines and user expectations for the systems are different, and those differences should be reflected in the UI designs.
If you really want to have a single UI for all platforms, just create a web app instead.
I'm not sure exactly what you mean by an "animation centric" design with seamless state changes. If you use multiple Activities, Android will animate between them in a way that Android users will expect. If you explain what exactly you are trying to accomplish, we can help you figure out if it makes sense in Android, and if so how to accomplish it.