-
Notifications
You must be signed in to change notification settings - Fork 12
DevelopmentProcess
When developing mobile applications with Mobile Application Framework (MAF) and the A-Team Mobile Persistence Accelerator (AMPA), we typically distinguish the following main tasks in the development process:
Everything starts with a visual design of the mobile app. Once this design is in place, you know what data you need to consume on which page and which data you want to modify, which allows you to optimize the design of the RESTful services that will deliver this data.
To build functional and performant mobile apps, the back-end data services need to be optimized for mobile consumption. RESTful web services using JSON as payload format are widely considered as the best architectural choice for integration between mobile apps and back-end systems. At the same time, many existing enterprise back-end systems provide a SOAP-based web service application programming interface (API). So, you might be tempted to start consuming these existing SOAP services in your MAF application. We strongly recommend to avoid the consumption of SOAP web services in your mobile application, mainly because of performance reasons. This performance study shows that SOAP services can be up to 33x times slower than REST-JSON devices when using older mobile devices. Even when your backend application API's are exposed through RESTful services, it is still a good idea to add a so-called mobile backend layer where you transform and shape these service to optimize them for consumption in your mobile application. A mobile backend layer exposing mobile-optimized REST endpoints has significant advantages:
- Application development will go faster since the REST resources and payload data structures match the screen design
- Application performance will be better because the amount of REST calls is minimized based on the screen design and offline requirements, and because only the data that is really needed for each screen is sent over the wire.
- Application CPU usage will be lower (and battery life will be longer) as no complex processing is needed on the device, this is all delegated to the mobile backend layer.
There are various ways to create a mobile backend, Oracle's Mobile Cloud Service (MCS) is the most comprehensive solution, including services for analytics, push notifications, file storage and security. Oracle Service Bus (OSB) can also be used to create mobile-optimized API's that are hosted on-premise. Oracle A-Team has written article series on creating such API's for both MCS and OSB:
- Creating a Mobile-Optimized REST API Using Oracle Mobile Cloud Service
- Creating a Mobile-Optimized REST API Using Oracle Service Bus
The model/persistence layer contains Java classes and associated files that represent the data model of your application. It contains the SQLite database which stores all data for offline usage, and two types of Java classes: data objects (aka as entities) that hold the data coming from the SQLIte database and/or the REST resources, and service classes that are used to perform CRUD actions and other custom actions that operate on these data objects. Finally, it contains the object-relation mapping information: how do database tables and their columns map to entity classes and their attributes, and how entity classes and attributes map to attributes in the REST resource response payload. The AMPA Business Objects from Rest Service wizard will generate all of the above artefacts for you.
##Create User Interface Layer You will typically create a bean data control for each service class in the model layer, so you can build your MAF AMX pages in a visual way using drag and drop from the data control palette in JDeveloper. In other words, building the UI layer is no different when using AMPA, the only difference is that you get a very powerful data control "for free". However, for quick testing of your model/persistence layer and/or user prototyping you can also use the AMPA MAF User Interface Generator which auto-generates a complete MAF feature including taskflow, amx pages and data bindings (page definitions).
UI logic is typically coded in managed beans, however put as much logic as possible in the model layer, this will make development faster, and your code will be easier to understand and maintain. We have seen many examples of extensive Java coding in managed beans, with programmatic invocation of binding operations defined in the page definition, or programmatic evaluation of binding expressions which often is not needed. While MAF development follows a Model-View-Controller architecture, the Model layer of a MAF application is never reused with another view technology, so be pragmatic, a tighter coupling with some UI logic in the entity or service class is really not a problem, it will make your life much easier!