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.
Related
I can't seem to find an answer for that. How many fragments can an app have, or how many xml layouts in general, before it starts getting cluttered and slow? All I found was that with too many nested layouts the activity itself performs worse.
Yes, theoretically it can. But it's not the number of fragments which can make an app slow, it's the way you use them. Even 2 fragments, if badly used, can make an app slow. On the other hand, tens of fragments could be handled fine. If your app instead needs 50, or 100 fragments, unless it's a really complex app and you're on top of it, then it's a good indicator that you're doing something wrong, either in the app flow, or the design. Android Studio provides you very good tools for profiling an app, use them, see where your bottlenecks are, and fix them. Measure the improvements before and after the fix.
No, there is no limit on making any number of fragments in Android app. And it does not harm any app if you make hundreds of fragments. But the way you are using those it DOES MATTER. As far as the matter of nested layout is concerned, yes it all depends upon your hierarchical level. Suitable approach should be used. Obviously not all layouts you will be showing in your activity. On depends or in certain conditions you will be using different nested layout. If this is the case then you can use fragment for dynamically update the UI or the Activity or Secondly you can dynamically add the views in your activity on demand. All at once if you are going to show complex nested layouts and those are in deep as well, this can cause sometimes some jerk or flick to load.To overcome this, You need to first think about weather it is necessary to load all the views else load on demand. Hope that helps you.
I'm an averagely experienced Android programmer.
I'm currently working on an app that includes the google maps API and among the activities there are two views that include a map fragment. Now I want someone to be able to navigate on one of those views, called mapActivtiy. It basicly consists of a map, that's all. After choosing a location in another view, I want the map to display the direction from the users position (which I already know) and the target's location.
Now, in iOS I'd just throw in the MKDirections stuff from the MapKit framework, but I seem to be unable to find something equivalent for android. Is there any API or something for wayfinding and navigation on the map? If so, where to look for it?
Just to clearify this: I know I can call the google navigation app from my app, but I don't (really) want to do that, I'd prefer staying within my context. Using the navigation app is more of a last resort.
Does anyone have a smart adivce for me?
Any idea would be much appreciated!
I have this application I want to upgrade from Google maps API 1.0 to the 2.0 especially for some performances issues.
Now, the application was designed (not by me) with a single Map defined in the unique main activity and use through the different fragments (included in the fragments as a View).
I am reading about the new api and have doubts:
1) Is it good to have 2 fragments on the same screen, one just for the map and the other one for other UI? This way i can create the effect of expanding/hiding almost completely the map with is such in fashion right now?
2) Have you knowledge about some guidelines to upgrade the API? I run on content about how to create with Api 2.0 but not to upgrade: rules, errors, guidelines?
Thank you a lot.
Edit: As always, I am working on it right now and I will post my solution/choice when I am done.
1) Is it good to have 2 fragments on the same screen, one just for the
map and the other one for other UI? This way i can create the effect
of expanding/hiding almost completely the map with is such in fashion
right now?
Yes it is expected within the framework to have multiple fragments on the screen and is a large part of the reason they exist.
2) Have you knowledge about some guidelines to upgrade the API? I run
on content about how to create with Api 2.0 but not to upgrade: rules,
errors, guidelines?
The Getting Started section should help you somewhat on this transition. If there is something specific you are looking for such as optimizing memory during the placement of markers on the map it would be best to search for that as needed.
1) Is it good to have 2 fragments on the same screen, one just for the map and the other one for other UI?
Depends on what data you want to put on one screen. It is often a good idea to have most of the UI-related logic inside Fragments instead of Activities, because they can be arranged differently on phones and tablets.
This way i can create the effect of expanding/hiding almost completely the map with is such in fashion right now?
Animating might be problematic. See Issue 4659 and Issue 4639.
2) Have you knowledge about some guidelines to upgrade the API? I run on content about how to create with Api 2.0 but not to upgrade: rules, errors, guidelines?
IMHO the best way is to forget (delete) all the code related to v1 and start from scratch, following official documentation.
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.
I'm currently trying to have 2 maps v2 in different tabs of a TabActivity using MapView objects. The problem arises in the following scenario:
tab1 with a map is displayed
go to tab2 in order to display another map
in this second tab looks like the map image from first tab is overlapping the new map. See the following picture:
On the right you can see how the first map is still displayed on top of it. The touch events are going to the new map but that doesn't really help. I spent a lot of time trying to convert our app to use fragments and run into other types of issues. One of them being http://code.google.com/p/android/issues/detail?id=40035 so that's not a good option either.
So far I haven't been able to find any workaround. To easily try various changes I wrote a simple application and made it available here: https://github.com/cristizmf/TestMapsV2. It needs only the right location for maps library project and a good maps key in manifest.
Any ideas would be greatly appreciated.
Later edit: I've logged an issue for this: https://code.google.com/p/gmaps-api-issues/issues/detail?id=5027&thanks=5027&ts=1362071369
We are having the exact same problem. I suspect this is caused by the fact that the new maps uses OpenGL - possibly android cant deal with having two OpenGL widgets in the view hierarchy at the same time even though one is hidden.
The only way we worked around this was to actually remove the mapview when leaving a tab, then construct a new one and add it back in when going back into the tab. This ensures that there are never two maps constructed at once.
Nasty, but it worked.
I ran into the same issue a few days ago and was pulling my hair out over what to do.
Originally I had my app set up with "Tabs the Fragment way" as seen here to avoid the deprecated TabActivity, and used this hack to allow me to incorporate Maps v1 in with the Fragments. It basically just masks an Activity as a Fragment.
But then switched to TabActivity further down the track for simplicity / it was better suited for the whole app.
But now obviously this 2x Maps v2 fragment problem has become an issue..
So I have reverted back to "Tabs with Fragments" and just have the "hack setup" as mentioned above for each tab, which allows to have an Activity for each tab, AND having more than one Maps v2 displaying for each Tab. I haven't gone into too much depth with it, but it seems to be doing the job atm, with having just thrown some code together to test it out..
Don't know if you're still having an issue with this / this obviously isn't the most correct solution, but just thought I'd share my two cents incase you still needed it.
Cheers.