A good form can make a spectacular difference. There are tests in which the best answer forms had 10 times more response than the...
Creating Enterprise Apps with MADP (MADP Blog Series part 2)Yakup Kalin
In this second part of the MADP blog series, we’re going to dive deeper into the benefits and the technical parts of creating mobile apps with a MADP.
As mentioned in our previous blogpost, developing (enterprise) mobile applications in the current fragmented mobile landscape can be challenging. Targeting the wrong audience and lack of security / good integration can introduce surprises and pitfalls along your mobile enterprise journey. In this blogpost, we will cover those challenges by exploring MADP with its benefits:
- Delivering fully native apps with 60-90% re-use of code across device platforms.
- Decreasing test time by 90% and app project costs by 40%.
- The possibility of building fully reusable components.
One codebase for them all
In my opinion, the most important benefit of MADP is that you’re working with one codebase for multiple mobile platforms. This is like water on a hot summer day for developers. Having one codebase means a developer needs to master only 1 development language instead of multiple. We’re also talking about 1 back-end integration, 1 error handling, 1 bugfix per bug and 1 feature integration per new feature.
An example: changes within mobile apps (with and without MADP)
I always love to explain this case using the new button example. Imagine as a company that you have a branded Android, iOS and Windows Phone app on the App Stores. After 5 months, you decide to add a contact button to make the app more interactive.
If you didn’t use a MADP, you’ll have to dig into three separate mobile projects (Android, iOS and Windows Phone). Each with a different codebase based on a different development language. I think you’re getting the idea here. Unless you have a developer in your team mastering all three development languages, you need to find, in the worst case, 3 developers. And if you didn’t invest in knowledge transfer within the development team, you’ll deal with a very low and critical bus factor. On top of that, you’ll probably need to update the three IDE’s if you last touched them 5 months ago. After this slow start, you finally manage to add your button. And once done, you need to build and package the mobile apps following the OS specific build guidelines.
If we retake this journey using a MADP, we find out that dealing with one codebase
- eliminates the hassle of changing/building and packaging apps;
- increases the bus factor;
- elevates knowledge transfer.
E.g. with one command, a MADP triggers the underlying OS specific steps to build and package your mobile app. This is one of the most important benefits of a MADP.
Write once, adapt everywhere
As stated above, when using a MADP, you’ll have to write one codebase. But still, there is a need of OS adaptation due to the different OS ecosystems and UI guidelines. A MADP does cover (some) OS UI guidelines, such as a tab bar that is automatically placed on top for Android and on the bottom for iOS. But the OS adaptation is a must for getting a good harmony between the specific OS and your app. You don’t want to enforce your mobile users to adapt new habits (e.g. Google material design principles on iOS), which could cause great confusion.
Once your adaption is in place, you can talk about realizing fully native mobile apps. This means you’re dealing with native components, their native performance and look-and-feel. There is of course a small penalty you get due to the mapping layer that maps your MADP code with native components, but that’s often not worth mentioning. In case of high hardware demand and/or animations, 3D rendering, etc., there could be some hassle. If that’s the case, you shouldn’t go for a MADP platform. Because native mobile solutions will provide and ensure very high performance, hardware and/or animations. Like I always preach: “The best tool depends on the specific case“. For more information about choosing the right tool for the right case, take a look at the presentation available here.
Reuse like never before
A MADP also helps you reusing your code. Since you’re using one development language, a piece of functionality within project A is theoretically fully reusable within project B. But I do have to say that the specifications of the project and code quality will increase or decrease your reusability rate across projects. Imagine having a piece of code for scanning a QR code written within project A (iPhone app). If you want to reuse that part within project B (iPad app), you’ll have to validate the reuse first. Why? Because different form factors could require different screen layout approaches. If there is no form factor difference, the direct reuse rate will be higher. Overall, the reuse rate of MADP lays between 60-90%.
Below you can find an example of reusing code across apps (iPhone/iPad). The 2D flat car for indicating damage on a car is fully reused.
How about testing?
Testing gets a lot easier because of the one common codebase. Writing unit/acceptance tests is only required once for all platforms. Without a MADP, in the worst case scenario, you need to write the same scenario/unit test multiple times for multiple platforms in those different languages. Besides increasing your test time, this also increases the project cost!
Appcelerator Titanium as our MADP
Mobile is a fast changing business. So it’s important to focus on the right thing, which is delivering suitable mobile solutions. MADP eliminates the hassle of keeping up with multiple codebases (and development languages) and elevates code reuse and knowledge transfer. So, you’ll have more time for spending on delivering better mobile solutions faster.
There are many other MADP benefits such as easy integration of mobile analytics, MBaaS and third party API’s (e.g. Salesforce) that will boost your mobile enterprise journey. But we will get more insights about the future of MADP and the importance for enterprises in the near future. So keep an eye out for our upcoming blogpost by Stijn Wijndaele (Mobile Business Unit Manager), you don’t want to miss what’s coming up!
In need of a mobile partner?
Do you have questions regarding mobile in your company? Are you looking for your future mobile roadmap?
The ACA Mobile team can help you!
Want to be informed of our latest blogs?
Want to receive updates about our latest whitepapers, blogs & ebooks?
Subscribe now to our mailing list and you will always be the first to know!