This week I have installed and run my first Kotlin application on an Android emulated device. I have also investigated market demand for mobile applications and have noted the following observations from my research:
mobile users generally only tend to use a few apps on a regular basis
freemium apps tend to be widely downloaded, to allow end users to gain an understanding of how to use the app and gain some valid use of it (test drive the app)
real estate space on a mobile tends to be extremely precious so end users tend to be very selective about the type of apps that they put on their phones
using the revenue generating model of having some minor advertising space on a mobile screen of an app looks at being a viable option to help mitigate the cost of production and operation of an app (cloud hosting of APIs, cost of registration with iOS app store and Google Play)
I looked at App Store Optimisation, searching for the right keywords and also on page optimisation for the Pocket Pal app. The keywords I am looking at for this Pocket Pal app are health, psychology, depression, anxiety, manage my anxiety, counselling, therapist
I am looking more at app store optimisation for marketing for my apps, and these will apply to all the apps. My revenue generation plan is to make the apps freemium, and to do ad placing within the apps, down the bottom of the app. This blog article lists out a number of methods for earning revenue from building apps. The video ads, even though they do earn significant revenue run the risk of being uninstalled as videos become a source of extreme frustration for some end users, and a small banner ad is likely to be able to remain on app without the app being removed from the mobile user's device.
https://mlsdev.com/blog/how-do-free-apps-make-money
One of the app marketing research strategies is to do an analysis, like in the following screenshot. In the spreadsheet, an app builder looks at items like the geography (location of the end user), the problems of the end user, the essence of the app (and the problem that the app addresses as part of it), the customer terms (search strings, including long tail keywords), the sales conversations and tools for ideas.
I completed the project template for the mobile app, including wireframes, ux/ui design, user stories and timeframe. I uploaded it to my main website mobile template.
I was required to build a simple calculator app, and also a very basic Android app. I found a tutorial for building a calculator app, and also looked at more videos surrounding how to navigate around Android Studio. I wrote out the code from this tutorial: Crunchify Calculator App. However, when I went to build the app, and run it on the Google Pixel mobile emulator, it had build fails and said that Apptivity was incompatible and so forth. This looked like a complex issue, like when I was setting up environments for PHP and using Composer; DevOps makes a lot of sense when we are wanting to get our code to run in a particular environment, so I figured I would have a look at this later, or build another app from the Udemy course I was doing. The Kotlin Bootcamp would likely help me make more sense of this problem too. I really want to build the Pocket Pal app in React Native, as it is cross platform, and I would like to simplify all my development. My next task I am going to look more into using the Keras/Tensorflow in the build for the AI.
I started the Kotlin Bootcamp, after having some build fails in the Java. I was investigating a lot of time into how to deploy the mobile app I am creating, and looking at creating APIs and hosting these on various cloud providers. One of my other subjects looked into Cloud service providers, and I am examining these as to their viability for application, particularly in a service model where I am monetising my app via the banner ad down the bottom of the app. I have had no previous experience with Kotlin, so diving into this seems a necessary part of this.
Android has a standard design theory or methodology so that end users have a consistent experience across apps used in the Android operating system. It uses Material Design, as opposed to iOS, which uses a flat design type. Material Design involves an "ecosystem" that involves a merging between a flat concept of a mobile surface, and the merging of the real world. It involves having hierarchies of dimension in terms of interaction and navigational experience and aims to be more responsive.
Flat design involves having interactions between an end user that are seamless, and also high performing. It is a concept that evolved to create simplicity in use between the end user and the app. Material design involves a deeper element of design, and through the use of the addition of gradients, skeuomorphism (representation of real world interactive elements in the digital) and a consideration of the z-axis in the physical plane.
Flat design asserts that end users are familiar and cultured in interaction with digital elements, and that additional traits of design make for a far more cluttered interaction, but material design attempts to merge the more fussy elements of user experience into a standardised and attractive package. It makes allowances for skeuomorphic design and additional affordances in a way that still reflects the performance, and streamlined experience of flat design.
When an app is designed, it is considered in terms of its users, and how they have previously been exposed to the experience of other apps in their operating systems, and the use of the app still has to reflect some intuitive components. For this reason, the elements of material design have been taken into consideration with making them a convergence between both being good in terms of user experience, but also for a standardised and somewhat uniform experience. An end user should know that they are using an Android app, due to its consistency in Material Design principles.
In terms of navigation, Material Design breaks its Android app styles into systems of hierarchies, namely the ViewGroup, a 3-Dimensional chain of interaction (similar in thoughts to a family tree) that has views as part of its system, and the views as subsets of those. Widgets can be placed within views. Widgets are collections of UI components, that together form a miniature system within an app (for example the chat part of a social media app).
There are layout styles that Material Design specifies - these include linear, constrained and relative. The linear design of navigation means that the end user goes through the app in a front to back method, similarly as they would to a book. Constrained design keeps all elements locked in a particularly hierarchy, and relative means that the components have more of a fluid layout, being able to flux around relative to one another.
Relative design is useful, because it avoids the need for nested components, and allows for keeping a hierarchy of components flat.
I worked on the Google Codelab for Navigation, to be able to get a practical understanding of these ideas.
The navigation design component within Android studio I found quite intuitive, and made sense from designing an app, and seems to transform the experience of previously designing interaction and navigation on paper to now doing design and navigation straight into the app, and avoids some double handling. It also enables to revise the navigation and to test it while it is being developed.
Android has integrated the development of Lifecycle - Aware - Components that help to manage state and responsiveness to other components and fragments within an app; the goal of lifecycle aware components is to reduce the amount of code that needs to be written
Life cycle events and state are managed from the lifecycle class and the framework; they map back to callback activities and fragments.
Application logic flow in Android apps follow along the standard App architecture for control flows of the user experience; this creates consistency in end user experience
In an Android app, each application is run on a virtual machine within the operating system, and operates on the principle of least privilege. This means that the app has access to the bare amount of resources possible in order to operate it. Considering that the application is run inside a virtual machine, and operates independently of each other app, the app architecture of an Android app is designed in such as way as to adhere to these system requirements.
App components are the building blocks of each app, and developing with the principles of clean architecture helps to keep this foremost in the mind of the developer. App components chiefly consist of Activities, Services, Broadcast Receivers and Content Providers.
In terms of control flows, states are the nodes contained within an application control flow diagram, and the edges are the events between the nodes. The above diagram summarises the logic flows of an Android application.
Activities - these are entry points for interacting with a user. They represent a single screen with a user interface. An app can consist of a number of activities, and help manage interactions between the virtual machine and the operating system. It allows for the destruction of one particular activity, and the creation of another activity (for example, searching the email inbox, then writing an email, or reading an email all occur as separate screens, with single entry points).
Services - these do not provide a user interface, but they do keep an app running in the background; for example the Australian Government's COVID-19 Safe app runs Bluetooth handshaking in the background if someone has been registered as a corona virus carrier. People are then notified to contact a medical service provider as a result. Services that run in the background also allow for things such as music playback even when the app screen is not open.
Broadcast Receivers - receive system wide notifications, and provide information if necessary to the user about state changes or the occurrence of events; for example, push notifications.
Content Providers - function similarly to a database, they hold information or other files as part of the system, and allow for the user to interact with that information when necessary.
Management of State
Activities, Services and Broadcast Receivers are activated by an asynchronous message called an intent. They define the action to perform, and deliver these messages to a specific component, or a type of component. Intents are similar to methods, as they describe an action and its requirements. Content Resolvers work directly with Content Providers, and are only activated when interaction with the files is necessary.
Classes, Lifecycle Owners and Lifecycle Observers
LifecyleOwner is a method interface that indicates that a particular class has a Lifecycle. It abstracts the ownership of individual classes such as AppCompativity and Fragment, and allows writing for components that interact with them. Lifecycle Observers watch and monitor the states and events within a Lifecycle, and this helps to manage various activities; for example if something changes within the system, it allows for callbacks.
The App Activity Cycle and User Interface layer are managed through the architecture of the app, and clean design is considered as best practice. Best practice recommendations for Android mobile development include implementing a presenter class for complex applications, to ensure that the lifecycle of the user interface elements is much more easily managed.
Recycler View is the successor to GridView and ListView. It is more extensible, because it allows for both horizontal and vertical layouts. There are three components to using Recycler View, and these include: The RecyclerView.Adapter, allowing for data that is incoming and written in a CRUD format where utilised to be collected and bound to the View; the LayoutManager assists in the positioning of items, and the ItemAnimator assists with both removal and addition of items within the view. There is a procedure for implementing RecyclerView, and this is implemented here as an example and instructional.
Internet Connection in Android apps requires accessing permission from the user in the device, and these are set within the code of the app, and in the App Manifest. These lines must be added to the App Manifest in order to indicate that permissions will be required on installation, and at times using the app, depending on the types of activities and services.
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
Connecting to the internet in an android app requires that communication be sent via secure socket layer (SSL) communication, and most Android apps communicate via the HTTP protocol; HttpsURLConnection client is the one most used by Android developers to both send and receive information across the internet. Network connections must be introduced in a separate thread to avoid problems with the user interface and main activities, and data is parsed with the client via a bytestream, and then converted within the client. The bytestream is parsed by the InputStream within the HttpsURLConnection client, and presented to the end user within the UI. Other network activities include the AsyncTask, IntentService and AsyncTaskLoader. Some apps will interact with a number of APIs, or have custom cloud data sources that they use for CRUD operations.
Fragments were created to suit Android tablets and other larger devices; fragments represent their own individual activities which hold their own architecture and state, within the whole frame. These fragments are updated individually, and work similarly to the React framework, where individual parts of a web page are updated within the DOM and the virtual DOM. This helps to reduce the overall load on the operating system, as only a particular part of an app is refreshed on the user interface, and it changes in response to different changes within other fragments of the app. Having fragments in Android tablets allows for more complex application design and more involved user interfaces.
Android Libraries can be included that are pre-written, standardised code, and these allow for a developer to produce code within an app in less time. They handle standard activities (such as internet connection or image handling) and allow the developer to integrate these easily into the application, without having to write customised code. They are easily added to an app, and Android studio handles the dependency injections and Gradle actions.
Geofencing is a service that can run in the background of an app; it can be useful for sending push notifications to a user of discounts if they are nearby a particular store that can offer a discount. Users have to be notified of the reasons for the geofencing service, and to give permission for location services, or geofencing to be used. Geofencing has a number of use cases, including the following: keeping children, pets and elders safe via notification of geolocation to caregivers; item shipping and location updates can be implemented by geofencing; providing a better app user experience for example recommending certain services within a geographical area; location based marketing (use case where the customer is sent discounts); data collection (for example phones can collect certain anonymous user data and it be aggregated into information such as number of people using a particular operating system in a geographical location); geofencing was used to indicate where groups of people were breaching social distancing requirements in certain countries recently; geofencing is also useful for helping with public transport coordination and for supply chain events.
Firebase is a specific cloud service developed for the mobile platform, it offers a variety of APIs as a software as a service platform (SaaS), including database storage, login handling, machine learning tools, cloud functions, authentication, file storage and other appropriate cloud services that scale for mobile application use. In-App messaging can be used, apps can be monitored, Google Analytics can be used on the app to indicate statistical use and where features of an app are widely used. It is a simple to implement cloud solution for mobile application developers who do not want to have to develop and host back-end APIs for their applications. Firebase provides for real-time application cloud services. It is also a lot simpler to implement a mobile app via using a facility such as Firebase than to have to decide on various other cloud platforms, or having to create an on-premises application API server. It may not be suitable in all cases, particularly when apps are being deployed in other services such as iOS.
Android comes with a Media Player Framework; it includes multimedia support for a number of different types of digital media content. This means that many different types of content can be played and interacted with in an app. MediaPlayer and AudioManager are the two classes that enable both audio and video files to be played back in an Android app. To stream media from the internet, the app will require permission from the user (indicated in the app manifest), and also it may require other modifications such as wake lock permission, to prevent the screen from dimming or the processor from shutting down if media is playing. The user will be notified on installation if they need to give the app permission to implement these features. MediaPlayer can connect to local file storage, or internal URIs (via a Content Resolver) or external URIs (internet streaming). MediaPlayer is state based, meaning that it is important to follow application control flows, such as initialisation, preparing the data source (particularly if downloaded from a remote location) and creating the state to play. What happens when the app activity is shut down also needs to be taken into consideration. Below is the state diagram for MediaPlayer.
Android Widgets
Widgets for Android live on the home screen of the phone, and are typically very small snapshots of a larger app within the phone. These typically fall into a number of categories, including information, collection, control and hybrid widgets. For example they may display the weather information on the home screen, or some calendar information. They may offer a rotating stream of photographs from the user's photo collection, or display events for that day. They are also there to offer shortcuts to controls within the phone, and may do things such as encapsulate controls for media players and cameras. They have to be suitable for purpose, and be a minimal part of a larger function. They may act as a shortcut for example, to quickly engage the camera for a photograph, or display a summary of news articles, share information, or brief email titles.
Swapping to Kotlin, after the failed Java Calculator app, and also signing up for a Udemy Android Developer course means that I decided to take somewhat of a deviation from the standard course, and felt that this would offer me a complement to my learning portfolio, rather than to detract from it, and also give me an adjunct to understanding of the Android app development process. I've been spending considerable time understanding the theory behind Android app development, and design of these, and how to provide a good user experience. I have found that using Android Studio has been a steep learning curve for me, as I have previously been frequently using Visual Studio, and Visual Studio Code. For my main project, I am using React-Native, and Visual Studio Code, as I am familiar with these and to keep my processes and workflows efficient, have chosen to implement these in my final project, Pocket Pal.
For my example app for Android, I decided to implement an interactive game in order to demonstrate my competency for Android app development. I believed a game would be able to demonstrate my ability to apply all of the learning theory of the previous weeks.
I'll be using a cross-platform game development library for this game, libGDX, and then show screen shots here of my app running in a simulator.
I've used the libGDX project creator to start up this application; I have named the game run sloth run.
I've opened up my Android Simulator and started to run the project so that I can see it change with a hot reload as I create it.
This is the project built in the simulator so far; I will adapt the Udemy course app to include game assets of a sloth sprite.
Below is the result of my doing coding of an Android game, I have called it Run Sloth Run, and will be releasing it on Google Play within the next couple of weeks. =)