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.
Most online stores thrive on customer satisfaction and their loyalty towards their stores. In order to improve the long term relationship with the customers and earn their loyalty, stores come up with different ideas to keep customers engaged. One such idea is to award loyalty points to the customer based on their purchases. These awarded points can be used by customers as a discount in their future purchases.
Understanding the need, we recently published this new extension “Spree Loyalty Points” which adds the loyalty points functionality into the existing e-commerce system. With this extension a new payment method gets quickly added to Spree e-commerce stores. It also automates two features (a) awarding of the loyalty points to the customers on the basis of the configuration done by admin and (b) updating the points based on each transaction done on Spree Commerce platform. It also allow the users to redeem earned loyalty points while placing new orders. Continue reading
Recently we were working on a feature where we had to combine an image and audio to create a video on mobile devices. In iOS this can be done using AVAssetExportSessionthough – for detail see this link However, we could not find any native solution for this problem in Android.
FFmpeg is one such tool to tackle this problem but it is not available for Android officially. We tried few existing Android ports of FFmpeg but they were either outdated or didn’t work for us. So we planned to fold our sleeves and compile the library for Android.
Compiling libraries on Linux system is a fairly common task, download the source code of the library and run three commands:
As we wanted to use the FFmpeg library on Android devices, we can’t just use the executable generated on the Linux machine directly because Android devices have different CPU architecture, different instruction sets and modified Linux kernel (OS). So we needed to cross compile FFmpeg library for Android
Cross Compilation ?
The process of building executable binaries on one machine, and running them on another machine when the CPU architecture or the Operating System are different is called “cross compilation”.