Activities, services, fragments, helper classes etc. are main components of Android applications but its tricky to establish communication between these components. It’s tricky when one cares about writing reusable code – loosely coupled, plug-n-play-able. The goal here is to avoid tight coupling.
Tight coupling – Components keep references of each other and call methods on them directly. In the code below, we are keeping a reference of MagazineActivity inside MenuFragment. So, MenuFragment is tightly coupled with MagazineActivity i.e., it cannot function without MagazineActivity.
This is the last part of this 6 part series about Fragment Oriented Architecture in Android applications. In the previous post I talked about managing sessions in fragment oriented application. In this post I am going to talk about retaining view hierarchy of a Fragment after removing it from container and then coming back to it by popping the backstack.
When a fragment gets replaced by another fragment and the transaction is added to back stack, the expectation after a popBackStack() is to return to the previous fragment with its UI state intact. Activity backstack takes care of this expectation quite cleanly until a low-memory situation occurs. But in case of fragments, this isn’t the default behaviour. In a vanilla implementation, the replaced fragment’s view-hierarchy would get recreated upon returning back to it. Reason is that during a replace operation, all the destructive life-cycle methods get called till
onDestroyView(), which wipes out the view-hierarcy. Upon returning back, all the constructive lifecycle methods right from
onCreateView() get called, thus, recreating the view-hierarchy totally afresh. Reason for this flow is to keep ‘Fragments’ memory friendly. Without the view-hierarchy, a fragment is just a java object with a bunch of instance variables.
This is the fifth part of a 6 posts series on Fragment oriented application architecture. In the previous post I talked about efficiently handling back button press inside fragment. In this part I am going to talk about session management in Fragment oriented application, by explaining integration of Facebook SDK.
In a fragment oriented application, we can conveniently manage all session related code in the activity and all its fragments would utilise it. Facebook SDK is quite in sync with this approach. Implementation of Facebook session is closely bound to an activity. And then this session is accessible throughout the application. As has been discussed before, if an application requires to sign in from different portions of it, it will be way more convenient to have those portions as parts of the same activity. So that the authentication code need not be duplicated.
This is the fourth part of a 6 posts series on Fragment oriented application architecture. In the previous post I talked about Inter-Fragment Communication. In this part I am going discuss about elegantly handling back button press inside fragments in a fragment oriented application.
Android devices have a hardware back button which normally serves the purpose of going back through the screens/actions stack. Callback to a back button press event is received in the foreground Activity (
onBackPressed() event callback) which can be overridden and handled.
This is the third part of a 6 posts series on Fragment oriented application architecture. In the previous post I talked about Transaction BackStack and its management. In this part I am going to talk about Inter-Fragment Communication. It’s a general concept, not deeply linked to the context of this series.
It’s a communication pattern over which fragments should talk to each other. Ideally, a fragment should never keep a reference of another fragment or even, in best case, of the specific parent activity. So, how would two fragments communicate? Consider the following scene.
This is second part of a 6 posts series. In the first post I talked around basics of fragment oriented architecture. From this post onwards, I’ll be talking about it’s implementation details.
In this part I am going to talk about Transaction Backstack and few related methods that can be used frequently.
Transaction BackStack has often been misinterpreted as backstack of fragments. FragmentManager inside an activity deals with fragment-transactions rather than with fragments. An entry into this backstack is a ‘fragment-transaction’ which can be composed of one or more operations involving fragment(s). Reverting this would revert back all these operations together.
FragmentTransaction ft = getFragmentManager().beginTransaction();
Above, is a single transaction clubbing multiple operations.
This is a series of 6 blog posts which explains about Fragment Oriented Architecture in Android applications. In this first post, I’m going to explain what is Fragment Oriented Architecture and why shall one care. In subsequent posts I’m going to talk about following topics.
Recently in one of our e-commerce projects we implemented phone verification for users to have authentic accounts at our website. The requirement was to have one account per user to avoid misuse of offers provided by our service on scenarios like signup, high-value purchase, referring a new user to shop at our site plus other special offers.
So we decided to verify users using phone number verification that seemed more reliable than email verification since having multiple phone numbers is not as easy and rare as compared to having multiple email accounts. We then chalked out a simple approach that came out ineffective and needed a renovation.
Save a phone number corresponding to a user that he can verify later by the one time verification code sent to his phone. We then ensure that the phone number is not verified against other account to have an account per user on verification request. Things seemed to go well but didn’t serve the purpose as expected.
During our revisit to the approach we found out that a user still could create multiple accounts. If you missed it too, here is how it goes:
Suppose, a user say, Haitham signs up with account A1 and verifies his account with number, N1. Now once he needs another account to avail more offers he can simply edit his number to say, N2 and not verify it. Then he can create another account say A2, and verify this new account using N1. As in the application’s use case of ‘referring a new user to shop at our site’, he could add himself as a referrer using account A1 for A2. Hence, the whole idea of fraud detection and prevention was deceived.
Don’t associate a number with a user until the user verifies the number.
The simple change above solved our issue to all possible levels.
Preparing your app for Android L ?
While using native executables in our existing Android apps we observed that those executables were no more working with Android L. We came to know that Android has introduced one more security feature starting from Android L i.e
Executable must be PIE (Position independent executable).
To compile a library adhering to above security feature you just need to follow these steps:
- Set following LDFLAGS or linker flags :
--with-pic option while configuring the library.
Some libraries might use different configure options to compile the code with PIC (Position Independent Code) so to check all available configure options for PIC you can use this command:
./configure -h | grep -i pic
If there is no PIC option in configure script then you can try passing
-fPIC option with your CFLAGS.
Now, compile the project (make, make install) and it should generate PIE.
To check if you’ve successfully generated a Position Independent Executable (PIE)
You can use “hardening-includes” package on Ubuntu or Debian.
We were developing a Content Management System which is composed of different components, with each component having dependency on other components in the hierarchy.
Our CMS has the following structure :
- Site has_many pages
- Page has_many sections
- Section has_many embedded_modules
- EmbeddedModule has_many elements
For any component to be publishable, we need to ensure that not only a particular component, but also its descendants(children) should satisfy the criteria of publishability.
In our case a Page could be publishable, if all sections belonging to it were publishable. A section would be publishable if all embedded modules belonging to it were publishable. A EmbeddedModule would be publishable if all elements belonging to it were publishable.
If at any step of the hierarchy the criteria fails, not only that component should be marked as unpublishable but also upchain should be notified of unpublishablity.
If any EmbeddedModule gets unpublished then it must unpublish the upper hierarchy i.e its associated section, page and site.
To achieve this we identified that a shared module would be needed which can handle publishability of a component and should also be able to notify the publishability change to its parent.