I am building an android app. I am new to this, I found out an interesting activity UI development, But I don't know how to describe that property properly in android terms-(I SINCERELY APOLOGIZE FOR THAT ).I am adding a video, Please consider it.Free Flowing multi-directional Smooth scrollable android overlay UI (Please turn on the subtitles on)
How to have that kind of UI overlay suppose I want to display a large image or file with multiple clickable buttons on it[I have already tried various Image loading libraries to load big size images and to make that Multidirectional scrollable].But that's not the exact thing which I want (like you can see the above mentioned reference).
So how can I execute that?
Thank you In advance for considering your time.
I have a scenario which I think is pretty common in Android applications. I know partial attempts of solving the issue were made, but until now I have not stumbled upon the full implementation. I intend to try to implement such component and open source it afterwards, but I need your help in its design.
So basically my case is the following: I have list view showing image loaded from the web and text per each row. I want to lazily load the images, placing default for each image and substituting it with the real one only when the image is downloaded. I also want to keep image cache avoiding the need to download the images multiple times in short period.
Up to now I have found several implementations that are partially working including:
Tom van Zummeren's implementation of similar component with several well known problems
Jeremy Wadsack's refinement of the concept, which is more or less working
Lazy drawables source forge project.
I also saw several stackoverflow questions regarding the problem: 1, 2, 3
However I have one more requirement which makes my task a bit more complex: I allow the user of my application to affiliate himself with some of the images. I want to load the new images associated to the user whenever the user navigates to the home screen. From it he should be able to go see his images, even before they have all been downloaded and in this case again default placeholders should be visible (Note the cross screen transition). Such use cases are:
An app listing user's youtube videos
An app for facebook - consider the images of friends
An app serving news that supports user's favorites etc
Note that I want to start fetching the new data related to the user on the home screen to provide better user experience. I will keep the user-related data stored locally forever.
The question
So my basic question is what approach should I use for the implementation of the image downloading? I know that the Android manuals say Service should be used only when I want to execute task even when application is not running. On the other side I will start the image downloading on the home screen and link the downloads to UI elements just when the user navigates to the new screen (Activity) - user-related list view and I do not know how to achieve that with AsyncTask (not that I have a very precise idea how to do it with Service either).
Any suggestion will be greatly appreciated, including links.
Universal Image Downloader is a good library which helps you to do image downloading in background with your settings.
It has so many features that you can implement at your own way.
i have written a somewhat small application , yet it runs very slowly on IOS and Android devices , it seems to me that the device takes much time to render the GUI.
i made sure to require every component needed on launch time, my application consists of 5 tab panels , each one contains a navigation view with multiple panels , i have set the autoDestroy property of navigation views to true.
i used sencha 2.0.0.0 and 2.0.1.1 and phone gap cordova 1.7.0 , cordova 1.8.0
Any suggestions?
i made sure to require every component needed on launch time
Because this, your application launches slow. The main reason is all of your elements are added to DOM tree right at startup time (you can inspect your application's DOM tree by Chrome's debugger tool to see it).
The best practice to optimize responsiveness of your application is discussed somewhere, here's one of them:
PhoneGap 1.4 wrapping Sencha Touch 2.X - What about performance?
For your situation, a better way to implement is:
Divide your application into 2 main views, an Ext.TabBar and an Ext.Container
Listen to changes in TabBar clicks, if user changes from a tab to another, remove your view in the main container and add appropriate views. It ensures your application only contains exactly 2 views at any time.
Hope it helps.
Could somebody please explain the exact advantages of using Fragments? In what cases should we use Fragments?
For what I understand, this framework:
Helps reuse existing code - if I implement functionality in a Fragment, then it's relatively easy to display this fragment in multiple parts of my app, when the functionality is needed.
Helps dealing with multiple screen sizes - a device with a huge screen may be able to display multiple fragments at once, and for smaller devices I can display the fragments in separate Activities.
Is there more to this framework?
Edit:
I've been using Fragments quite extensively in a larger project for 3.0 tablets. To me the greatest advantage was that using fragments I could break up the logic that would go in a single, monolithic Activity into multiple, smaller Fragments. Big screens mean huge Activities, difficult to read, understand (especially to new team members), develop and maintain. Fragments certainly helped in this matter.
Is there more to this framework?
Animated effects available when dynamically adding and removing fragments from the screen
Automatic BACK stack management, so the BACK button can remove dynamically-added fragments before eventually exiting the activity
Integration with the action bar for tabs, as a replacement for TabHost
Integration with the action bar for "list"-based navigation (really a Spinner in the action bar, toggling between different fragments)
Somewhat easier handling of configuration changes courtesy of setRetainInstance(true)
Also, responding to #Jim Blackler:
I share your confusion, since it's always been easy to customize Views which seems (to me) to solve all the same problems.
Everything offered by fragments can, by definition, be done using Views, simply because fragments are built on top of the view framework. However, fragments make more complicated scenarios involving dynamic fragments a bit easier IMHO.
Moreover, fragments in conjunction with the action bar seem quite likely to be a long-term area of attention for Google, meaning I expect a fair amount of additional work in this area over the next 2-3 releases.
I have developed some apps for Android, and this questions stays always:
How should I structure my UI? Should I launch activity after activity and leave the phone to make the "back" button, or should I choose more optimized, but more complex to implement, way with switching manually Views and then manually doing the "Back" button functionality?
What do you think (or know) is the better practice?
I would say that multiple Activities almost always makes more sense. I just don't think Android is designed for constantly switching its own views - you miss out on so much. You have to implement Back yourself, you don't get any inter-Activity transitions, you have to implement a lot of internal logic to resume an application in the correct state. If you don't partition your app into Activities, it makes it a lot more difficult later on to change the flow of your application. It also results in one mega-Activity that can be a lot harder to handle than a lot of smaller pieces of code.
I have trouble imagining that speed is really an issue; if it is then there's something wrong with the way you're initializing each Activity. For example, I used try to pass Serializable objects between Activities, and that proved to be incredibly slow; when I switched to a faster method of passing objects, the speed of launching Activities increased immensely.
Also, I think it's telling that the Android guidelines for Activity and Task Design don't mention switching Views at all; it's centered around an Activity-as-View design.
I'd like to point out some instances when a single activity might be better design for an Android application that has more than one full screen View:
If the application screens are tightly coupled and share a common Object that they are all operating on. In this case passing around the Object may require a Bundle and can be error prone since there will be copies of it. A good example might be a wizard. Yes you could use static's to access the common Object but static can be dangerous in Android (think configuration changes!)
If you want some really cool animations in between screens. Maybe you want a bird to take off in one screen and land in another screen. Try doing that when each screen is an activity!
On the other hand if one of your screens is designed to be shown by any number of other applications then that screen should be its own Activity.
UPDATE March 2014:
At this point the question should now include the choice of Fragments. I think that Views are probably the least likely choice of the 3: Activity, Fragment, View. If you want to implement screens that make use of the back button then it should be either Activties or Fragments because both handle the back button natively. Fragments will need to be added to the FragmentManager back stack for the back button to work. Managing fragments, dialogs and the back stack can be a bit of an annoyance though!
UPDATE Sept 2018:
Some devs at Google are recommending single activity apps using the new navigation architecture component.
Also keep in mind that implementing your app with multiple Activities will give the user a more coherent experience with the platform as a whole. Part of the experience will be shaped by using the built-in Google apps, so users will probably have an easier time using your application if it behaves similarly to the ones that are already installed on the phone.
Different from others I use a mixture of both, for example,
1. There is a main menu when the application starts
2. You click on search, takes you to search activity
3. Then there's a filter button, which just switches view and shows you filter options
4. There are two buttons at the end of the filter view, You hit "Search" or "Cancel" and you are back to the Search View again (without switching activity)
5. Now if the user hits the phone back button he's taken back to the main menu instead of the search filter options. Which I guess is the correct behavior.
Use it the way user will feel natural. And keeping everything in one activity will make it complex.
It all depends on application, what are you trying to achieve better performance, smoother UI. IMHO I prefer the second approach of controlling the Activities manually even that it is more complex as you have stated. This is a approach I have used in my android tabs project, also you might want to take a look at a class called ActivityGroup (not sure the package) it allows you to have multiple activities that you can switch between, good thing about this class is that your activities are not unloaded when you switch but a bad thing is it takes longer to load your main app.
Just my opinion.
The problem with switching views, that I stumbled upon, is also caused by garbage collector. Seems that GC is triggered when you leave activity and not the view. So, changing tabs with a fairly complex children views, for instance, will almost inevitably lead to stack overflow exception..
I've experienced so many problems with multiple activity layout that I strongly discourage it, unless there's good reason to pick it.
Disadvantage of multiple activities
Using multiple activities it is much hard to refactor code to return data from activity.
If you call a 'sub'-activity then the main activity may be killed. But you never experience that while debugging on a decent device, hence you need to handle always saving state and correctly recovering state. That is a pain. Imagine calling a method on a library (ie. another activity), and you would have to be ensure that when that method returns your app must be able to recreate its state completely with all fields on all objects in the VM (ie. activity.restoreIntance). Its insane.
Also the other way round, when you open a subactivity the VM might have been killed since the subactivity was first spawned, such as when app is minimized while subactivity is displayed.
Its so much cleaner to just have one place to store the relevant app-state, and in my case, most often if VM is killed, I want to return user to main-screen, and let them do their stuff again, because I don't spend 30-50 hours coding save/resume functionality that 0.1% of users will ever experience.
Alternative
Fragments or just manage you activity views yourself. Managing views manually, requires coding some view-switching alternative to activities/fragments with transitions if desired.
And no it does not mean one mega-activity, as suggested in the accepted answer, in any other way than its one mega-app. It just requires a bit more design of the codebase into fitting pieces, because there's slightly more work managing views, though much less work managing activity-state and other weirdness.
Possibly relevant: Reddit: It's official : Google officially recommends single activity app architecture