Tuesday, January 7, 2020
About Me
Saturday, July 20, 2019
How to have an efficient mobile application
Friday, March 1, 2019
How to use fragments ideally in Android Applications
My suggestion is: do not use activities at all, instead use fragments, and replace them in the container (Linear Layout for example) where you show your first fragment.
The code is available in Android Developer Tutorials, you just have to customize.
http://developer.android.com/training/implementing-navigation/nav-drawer.html
It is advisable that you should use more and more fragments in your application, and there should be only four basic activities local to your application, that you mention in your AndroidManifest.xml apart from the external ones (FacebookActivity for example):
1. SplashActivity: uses no fragment, and uses FullScreen theme.
2. LoginSignUpActivity: Do not require NavigationDrawer at all, and no back button as well, so simply use the normal toolbar, but at the least, 3 or 4 fragments will be required. Uses no-action-bar theme
3. HomeActivity or DashBoard Activity: Uses no-action-bar theme. Here you require Navigation drawer, also all the screens that follow will be fragments or nested fragments, till the leaf view, with the shared drawer. All the settings, user profile and etc. will be here as fragments, in this activity.
The fragments here will not be added to the back stack and will be opened from the drawer menu items. In the case of fragments that require back button instead of the drawer, there is a fourth kind of activity below.
4. Activity without drawer. This activity has a back button on top and the fragments inside will be sharing the same action-bar. These fragments will be added to the back-stack, as there will be a navigation history.
[ For further guidance see: https://stackoverflow.com/a/51100507/787399 ]
Happy Coding !!
Tuesday, January 7, 2014
Screen Management in Android, J2ME and BlackBerry
1. As Android gives Fragments, (which was to manage the views in Tab devices mainly, I use it to reduce the number of Activities in the application), J2ME application should have minimum of two Displayables (Form, List, Canvas and GameCanvas) in the memory at a time, similarly minimum of MainScreen, FullScreen or PopupScreen at a time.
You can use IDs, and double buffering to repaint or show 'screens' on same displayable.
2. Keep minimum of Objects in the global objects, and remember to destroy them when no longer in use. So you must have onDestroy() for each 'screen' or 'fragments' you show in the view.
3. Use Adapter or WeakReference techniques to show the items in a list view; Pagination or Pull to Refresh techniques to show limited views on a View. Lazy loading to create and destroy the image objects once loaded in the SDCard memory from the network.
4. All the IOExceptions should be handled in a background thread as in AsyncTask in Android, and if the result is to be shown on the screen, use bundles to pass to it as a serialized object and update in the UI Thread. This feature is not in J2ME, but BlackBerry and Android have it.
5. In Android the concept of LocalBroadCast Manager can be used in communication between Services and Activities combining preferences. In BlackBerry you have GlobalEventManager and PersistentStorage, but you should transfer all the responses in both from IO Thread to another thread preferably a UI Thread, as the event manager should not wait, and to ensure proper UI refresh on the active screen. While there is a background operation, show a progress bar to prohibit user to cancel. If you want to use a cancellable progress bar, or if you can not prohibit user to do any action, cancel previous requests, using a Boolean isCancelled tracker.
6. Keep track of events like Swipe, Orientation Change, change in size of screen, device resolution adaptation, virtual keyboard show and hide, paused and resumed state of Displayable/MainScreen/Activity. All the recording of screen state should be done in a onPause() callback, and all the refresh activity in onResume().
7. There are design concepts for showing most of the contents in the same screen. Like you have Tabbed Panes, NavigationDrawer, ViewPager, ActionBars, Immersive mode, Context menus, 'SuperFish', 'Carousels', ScrollView and so on in Android. If these are properly implemented, gives user a comfortable experience.
Android Fragment Transactions
Here are some tips that I follow now while using fragments in my activities:
First you would like to achieve something like this:
https://moqups.com/abhsax130778@gmail.com/lc0ZOERO/p:a5d7b55eb
Then there are scenarios like:
-----------------------------------------------------
Scenario 1:
1. Suppose there is a fragment on an activity and a button on it. You click on a button and another fragment opens.
2. From there, you press on back/return button and you come to first fragment.
That is easily done using back stack.
Now you want to do the same using swipe. I mean coming from second fragment to the first using the swipe and not the back/return button.
You usually do it with a backstack, while replacing the fragment 2 with fragment 1 in the transacton when opening fragment 2 from fragment 1:
FragmentManager manager = ((FragmentActivity) this).getSupportFragmentManager();
manager.popBackStack();
---------------------
Scenario 2:
1. There are 4 tabs on action bar activity, and on each there is a fragment.
2. You click on a button on fragment 1 on tab one and it replaces with fragment 5 (while 2, 3 and 4 are on their tabs respectively).
you move to tab 2 and there is fragment 2, and when coming to tab 1, still there is fragment 5.
You left swipe on fragment 5 and come to fragment 1 remaining on tab 1 and this state is also maintained.
This you can do without transactions by having stack of fragments for each of the tab and pop when onBackPressed knowing what tab is active.
You do the same when the left swipe is detected.
[The stack for each tab is in another array arranged in the order of the tab displayed.
It updates the ViewPager adapter onClick and onBackPressed thus maintaining the navigation history for each tab.]
So:
==================================================
[Note: In case you are using FragmentStatePagerAdapter, you can play with replacing a fragment with another fragment at a particular index in the list of fragment that you are using as a data for this adapter, in a way that you are in the same tab but its content is changed without changing the tab. Then use notifyDataSetChanged(). Here you do not use transactions, but otherwise you do].
1. Use Fragment.instantiate() to initialize your fragments instead of
constructor.
2. Use listeners to update/delete the reference of instance
(from the collection used to refer them) of fragment onCreateView and onDestroy.
3. Use getView() to get the root view of fragment every where and on update functionality.
4. Do not keep track of instances, in fact avoid static pointers where ever possible.
5. Use getSupportFragment instead of keeping reference of FragmentManager in view pager adapter or elsewhere.
6. Use attach detatch on transaction hide view, to get rid of child views on Fragment's root view and re initialize.
This is because only one fragment needs to be visible at a time, the others need to detach.
Therefore re-attach on demand.
7. getActivity() or getApplicationContext() whatever applicable, instead of keeping a global variable to keep references to context.
8. onConfiguration change (orientation, keyboard, resize): do in activity and pass it to active fragment which manages it.
Important: If you do want to use fragments for transactions, do not declare them in layouts.
Provide container (layout) id in add fragment transaction.
9. A Fragment transaction should be done in an event call, not anywhere else, and such an event should not be repetitive. This prevents Illegal Argument Exception.
10. There is a ViewPager method where you do not have to use Fragments. Instead, you can use Views, or ViewGroups. This replaces the nesting of fragments.
11. Detect the level of fragments, that means if you want a fragment 'B' to replace existing fragment 'A', and when you want to go back to show fragment 'A' when pressing back on 'B', put that transaction in back stack.
-----------------------------------------------------------
Tip : Carefull while adding swipe feature because there are other clickable views.
Swipe with intercept touch on RootView returning false but analysing touches.
-------------------------
For the Swipe feature handling; properly in your ViewGroups:
Check which events needs to be intercepted and which are to be passed to the child views:
-------------------------
Swipe gestures on viewgroup
Instead of using my swipe gesture listener in frame-layout on which fragments are attached,
now I am using it on the relative-layouts which are the root-views of the fragments.
@Override
public boolean onInterceptTouchEvent(MotionEvent event) {
boolean intercepted = super.onInterceptTouchEvent(event);
// In general, we don't want to intercept touch events. They should be
// handled by the child view.
gestureDetector.onTouchEvent(event);
return false;
}
@Override
public boolean onTouchEvent(MotionEvent event) {
boolean touched = super.onTouchEvent(event);
gestureDetector.onTouchEvent(event);
return touched;
}
One more thing: you should observe that having one fragment in one container at a time resolves another issue: If there are two fragments , one on the top of the other, the clicks from one fragment goes to the other fragment that is beneath. So hide or replace to have just one fragment at a time. Back-Stack helps in maintaining the navigation levels, and on configuration change or update, try to update the same instance of the target active fragment, instead of doing transactions because that changes the order of fragments navigated.