Lecture Date: Wednesday, December 5, and Friday, December 7
There are two demo days: Wednesday, December 5, and Friday, December 7. Students are only required to come to their assigned demo day, but are highly encouraged to come to both to see all the projects! ALL project code for both days is due at 10:00 AM on Wednesday, December 5. ANY change to the code between that time and demo will result in a 0 for the project for both partners.
Teams demoing on Wednesday, December 5: Android teams + iOS teams listed below
You know what's better than a powerful computer in your pocket that can do a lot of what you do on your laptop? A powerful computer on your wrist that can augment a powerful computer in your pocket that can do a lot of what you do on your laptop!
We will compare and contrast Google's and Apple's strategies, hardware, and software. We will also look at where smartwatches began. We'll also get into wearable, personal computing at large.
As we discussed in the monetization lecture, determining which platform to build for can be a tricky decision. There are several aspects to consider:
Which platform has the most users? Android, definitely.
Which platform has more stuff in the app store and makes it harder to find things? Again, Android. Definitely.
Which platform is more expensive to develop for? iOS. (Macs are not cheap, plus $100 a year.)
Which platform makes the most money for developers? Probably iOS.
So, the answer than many compaines come to is that they need to develop for both Android and iOS to hit more of their market. One way to do this is to have two dedicated teams, one for each platform, that collaborate on requirements and design. This is how many mobile shops like WillowTree opperate.
However, in a large company whose main business is not producing software, there's a desire to optimize the time needed to produce an app. Also, if updates need to occur, it's best to make those changes in one place. Hence the desire for cross-platform development.
Cross-platform development for mobile basically comes in two forms:
Build with an API/toolchain that exposes the native SDK of the platform for a single programming language/system (i.e. C# with Xamarin)
Build a hybrid HTML5 web app that can execute as an app on the device (i.e. Apache Cordova)
It is estimated that Google brings in $1.1 million per day
Over 2013, the estimate is $1.3 billion in 2013 (13% of what Apple did)
The Google Play Store, however, is 75% of all total mobile app downloads worldwide (App Store is 18%)
Much larger install base
More phones and properties
Currently growing at a faster rate than the App Store
Most profitable Android apps are doing better than the most profitable iOS apps
Spring 2017 Update
Highlight quotes from the article linked below:
90% of Google Play income came from games.
According to App Annie, the average user spent over 150 billion more hours in apps in 2016 than they did in 2015. The number of hours spent in apps totaled nearly 900 billion. That’s good for about a 15% increase overall.
Download numbers stopped being the big metric that developers and pundits used to calculate an app’s success. Things like daily active users (DAUs) and time spent in an app became the more important metrics.
The number of downloads increased by 13 billion from 2015. Total apps and games downloads were over 90 billion overall. That’s a growth of 15%. Much like 2015, Google Play saw more download growth than Apple. China also contributed about 80% of Apple’s download growth.
In 2016, India surpassed the US in overall downloads while Brazil and Indonesia saw good growth. Four of the top five countries in “time spent in apps” were also developing markets.
The idea of analytics is the gathering, processing, and interpreting of data. The concept of analytics is not new (consider any program you have used that asked to send data back to the developers), but the ready capability to do analytics with web services and cloud computing has made it now more easily available to anyone.
The code isn't all that exciting... the best part is that we can add events to actions that we want recorded. For instance, when you press the "Feature 1" button, here is what is called:
Toast.makeText(this,"Tychonievich is very smart. He likes Feature 1. So you are smart too!",Toast.LENGTH_LONG).show();Bundlebundle=newBundle();bundle.putString(FirebaseAnalytics.Param.ITEM_ID,"Feature 1");bundle.putString(FirebaseAnalytics.Param.ITEM_NAME,"Feature 1");mFirebaseAnalytics.logEvent(FirebaseAnalytics.Event.SELECT_CONTENT,bundle);
Now that you've seen the system in action, what sort of thing can and should we record about our apps?
There are two vectors to consider: who is using the app and what are they doing in the apps.
Let's start with the what. Software engineers call a profile and likelihood of how often certain features are used an operational profile. Operational profiles are incredibly important to manage how you build and maintain an application. Consider features like print and save in a word processor versus mail merge. Some features simply require more attention because they are going to be used extensively. How do you know what parts of your app people use the most? Wouldn't you want to know that? How would you use that data?
Then there's the who. If you could pair the operational profile with info regarding your users, then your development could be even more targeted. What aspects of a person would you be most interested in?
returning user vs. new user
how long people use the app
what device they use
what network are they on
What pieces of data would you want from your app to make it successful?
Between the information we gather through sensors and also through analytics procedures, we need to be fully transparent regarding what we do with users' data.
Gather - how will the app collect it's data; can the user opt-out
Use - what will the company do with the data
Disclose - will the company give (or sell) the data to other entities
Manage - can a user ask for their data "back" or even deleted; how is the data stored; is it archived
Today you will begin to create a digital wireframe of your final project app. Please upload a PDF copy to the root of your final project repository AND each partner should submit a copy to the appropriate assignment in Collab. We are looking to see that you have a good idea as to what your project should look like. We will not be comparing this wireframe to your final app at this stage.
You can use whatever digital tools you would like to create the wireframe. There are dedicated wireframing tools available out there - some free, some pay. You are welcome to explore these options, or use something else, such as Photoshop.