Difference between revisions of "GravidPluss:Roadmap for App Development"

From its-wiki.no
Jump to: navigation, search
(Design)
 
(7 intermediate revisions by 3 users not shown)
Line 9: Line 9:
 
|User=Josef Noll, Mirjam Lukasse, Iñaki Garitano, Seraj Fayyad,  
 
|User=Josef Noll, Mirjam Lukasse, Iñaki Garitano, Seraj Fayyad,  
 
}}
 
}}
 +
= Meeting 28Mar2014 =
 +
contributors: Inaki, Seraj, Josef, [[Serhat Sama]]
 +
 +
== Outcome ==
 +
* updated requirements for information from project (who to measure, what to transfer)
 +
* first draft of requirements for app
 +
 +
= Meeting 25Mar2014 =
 
Main focus on  
 
Main focus on  
 
* Roadmap for App development
 
* Roadmap for App development
Line 17: Line 25:
 
== Design ==
 
== Design ==
 
Design templates are ready. Use of Lato font family is okay for printed brochures, but might cause problems  
 
Design templates are ready. Use of Lato font family is okay for printed brochures, but might cause problems  
* in Android and Apple: '''Iñaki to check''' about size of download (which will increase the app size).
+
* in Android and Apple: the entire font set is about 1.1MB, where each font is about 120KB.
 
* For powerpoint we should use standard fonts, as a distributed powerpoint should look equal on all machines, regardless if the font is installed or not.
 
* For powerpoint we should use standard fonts, as a distributed powerpoint should look equal on all machines, regardless if the font is installed or not.
  
Line 42: Line 50:
 
* '''Lisa''' will work on the outer design. '''Iñaki''' will provide a framework for the design work.  
 
* '''Lisa''' will work on the outer design. '''Iñaki''' will provide a framework for the design work.  
 
* the first design will be created in an Android emulator on the PC/MAC.  
 
* the first design will be created in an Android emulator on the PC/MAC.  
* The real version will then be generated as soon as the design is stable. It takes 6-8 weeks to get an app approved in Apple Market, and about 2-3 weeks in Google.  
+
* The real version will then be generated as soon as the design is stable. It takes 6-8 weeks to get an app approved in Apple Store, and about 2-3 weeks in Google.
 +
* With Apple, there is a possibility to create in-house applications. This basically means that we will be able to upload the application to one of our servers and distribute it from there. To do so, we need to enroll to iOS Developer Enterprise Program and for that, an enterprise D-U-N-S number is needed. There is no limitation relating the number of devices.
  
We want to limit the usage of the app. The favoured suggestion is to use the mobile phone number as a "one time login" after installation. If the phone number is on our list, then the full app functionality will be opened. Otherwise only information is provided to users of the app. '''Iñaki''' checks the conditions for company development and roll out (restricted number of devices in AppStore).
+
We want to limit the usage of the app. The favoured suggestion is to use the mobile phone number as a "one time login" after installation. If the phone number is on our list, then the full app functionality will be opened. Otherwise only information is provided to users of the app.
  
 
== Infrastructure at the hospitals ==
 
== Infrastructure at the hospitals ==
 
Ullevål is probably the hospital with the most difficult solution to set up Wifi. We will first have a meeting with the data privacy responsible, which '''Mirjam''' will organise. Then we will discuss further the possibilities, probably already starting in April with checking the infrastructure.
 
Ullevål is probably the hospital with the most difficult solution to set up Wifi. We will first have a meeting with the data privacy responsible, which '''Mirjam''' will organise. Then we will discuss further the possibilities, probably already starting in April with checking the infrastructure.
 +
 +
== Suggestion ==
 +
Make the data collecting phase offline and data sending phase online. which mean the user have to be connected to the internet in the data sending phase just only.
  
 
== Kick-off ==
 
== Kick-off ==
Line 55: Line 67:
 
** Bluetooth set-up and blood sugar measurement units.
 
** Bluetooth set-up and blood sugar measurement units.
 
* Everyone is free to set up tasks for participants.
 
* Everyone is free to set up tasks for participants.
 +
  
 
=== AOB ===
 
=== AOB ===
 
''Forgotten something?'' Please add it on this page
 
''Forgotten something?'' Please add it on this page
 +
 +
= App dev considerations =
 +
== App on one device per user==
 +
We use the mobile phone number for first authentication, and then register the device ID and link the two parts together.... By that we ensure ''(i)'' that only those who are in the right group have access to the full functionality of the app and ''(ii)'' that giving the mobile phone number to another person will not help, because the installation is already taken...
 +
 +
=== Implementation ===
 +
After the info screen, "continue" will lead to a enter your mobile phone number (8 digits) screen. This one will be checked against a white list. The white list will contain the phone number, and the device ID (see below). If the phone number is in the list, then the device sends the device ID and can start working with the personalised blood sugar measurements.
 +
 +
iOS solution
 +
* Before iOS 6 developers were allowed to ask the devices about their UDID (unique device identifier). But because of the privacy apple does not allow this strategy any more. The applications that the device about UDID are dismissed right away.
 +
Solution
 +
* Apple created another number to identify devices uniquely, the identifierForVendor. This number is unique for each device and each vendor. So even if the same application is installed in two different devices registered with the same apple ID, the identifierForVendor will be different.
 +
 +
* URL 1: http://nshipster.com/uuid-udid-unique-identifier/
 +
* URL 2: https://developer.apple.com/library/ios/documentation/uikit/reference/UIDevice_Class/Reference/UIDevice.html#//apple_ref/occ/instp/UIDevice/identifierForVendor
 +
 +
Android device identifier
 +
* There is nothing like Apple's identifierForVendor.
 +
Solution  However, there is a solutions:
 +
* Android ID: a number created the first time the device is turned on. It is regenerated if the device is reseted to factory settings. Then it would be like a different device. But obviously, if you reset your device you loose all your blood sugar measurements so it doesn't matter if the application alerts your that you are going to replace your previous device and that you may loose all your measurements.
 +
* Google ID: I don't see it as an alternative because then we will not be a be able to distinguish two different devices own by the same user.
 +
 +
* URL 1: http://limbaniandroid.blogspot.no/2013/05/how-to-get-device-unique-id-in-android.html
 +
* URL 2: http://stackoverflow.com/questions/14657977/android-is-there-an-equivalent-to-identifierforvendor-in-ios

Latest revision as of 09:34, 16 April 2014


GravidPluss:Roadmap for App Development

Title GravidPluss:Roadmap for App Development
Place UNIK
Date, Time 2014/03/25, 0900-1200
Contact Person Lisa Garnweidner
Participants Josef Noll, Mirjam Lukasse, Iñaki Garitano, Seraj Fayyad
related to Project GravidPluss
Keywords
this page was created by Special:FormEdit/Meeting, and can be edited by Special:FormEdit/Meeting/GravidPluss:Roadmap for App Development
Category:


Meeting 28Mar2014

contributors: Inaki, Seraj, Josef, Serhat Sama

Outcome

  • updated requirements for information from project (who to measure, what to transfer)
  • first draft of requirements for app

Meeting 25Mar2014

Main focus on

  • Roadmap for App development
  • Requirements for apps
  • Bluetooth interface

Conclusions

Design

Design templates are ready. Use of Lato font family is okay for printed brochures, but might cause problems

  • in Android and Apple: the entire font set is about 1.1MB, where each font is about 120KB.
  • For powerpoint we should use standard fonts, as a distributed powerpoint should look equal on all machines, regardless if the font is installed or not.

The design is that universal that we might use it for a bigger project around pregnancy (worldwide?)

Questionnaire

Questionnaire roadmap includes three dates, prior to week 30, week 36 (og pregnancy) and 6-12 weeks after birth. The draft version of the questionnaire is ready. We will have three steps,

  • (1) prior to week 30, getting the initial data from the participants. Here we will also create the randomised participant number based on the mobile phone number and the hospital
  • (2) the second questionnaire, giving an initial feedback on habits, eating, activities
  • (3) the third questionnaire will take place 6-12 weeks after birth. We intend to use an SMS to remind participants to go to the web page and fill in the final questionnaire. The SMS will include a unique code, which will be used to relate the answer to the person.

Randomizer

Our starting point is that we use a random number generated from the phone number and the hospital. Thus, when the participant fills in the first questionnaire, she will add here mobile phone number, the week of pregnancy (to exclude if entered week 31), and the hospital. By entering the mobile phone number, and "return", the sheet will be randomised.

  • do we need to check that the number typed in is written correctly? That will require an own "sms sender" (from UNIK)
  • we need to establish Wifi infrastructure at all hospitals in order to be able to work "online"

App Roadmap

We foresee the first app being ready around July 2014, based on an Android Emulator on the PC. In order to make updates as easy as possible, we will have most of the information on the server, and only initial text and the outer design blocks on the device. This will allow and easier update of information without updating the app.

We concentrate on iOS (Apple) and Android (Google), as Microsoft is probably used only for 1-2 participants ("sorry, you can't participate).

  • Lisa will work on the outer design. Iñaki will provide a framework for the design work.
  • the first design will be created in an Android emulator on the PC/MAC.
  • The real version will then be generated as soon as the design is stable. It takes 6-8 weeks to get an app approved in Apple Store, and about 2-3 weeks in Google.
  • With Apple, there is a possibility to create in-house applications. This basically means that we will be able to upload the application to one of our servers and distribute it from there. To do so, we need to enroll to iOS Developer Enterprise Program and for that, an enterprise D-U-N-S number is needed. There is no limitation relating the number of devices.

We want to limit the usage of the app. The favoured suggestion is to use the mobile phone number as a "one time login" after installation. If the phone number is on our list, then the full app functionality will be opened. Otherwise only information is provided to users of the app.

Infrastructure at the hospitals

Ullevål is probably the hospital with the most difficult solution to set up Wifi. We will first have a meeting with the data privacy responsible, which Mirjam will organise. Then we will discuss further the possibilities, probably already starting in April with checking the infrastructure.

Suggestion

Make the data collecting phase offline and data sending phase online. which mean the user have to be connected to the internet in the data sending phase just only.

Kick-off

  • Josef to focus on both app development, opportunities, challenges, and restrictions.
    • advantages of using Web pages
    • using Bluetooth and phone interaction
    • Bluetooth set-up and blood sugar measurement units.
  • Everyone is free to set up tasks for participants.


AOB

Forgotten something? Please add it on this page

App dev considerations

App on one device per user

We use the mobile phone number for first authentication, and then register the device ID and link the two parts together.... By that we ensure (i) that only those who are in the right group have access to the full functionality of the app and (ii) that giving the mobile phone number to another person will not help, because the installation is already taken...

Implementation

After the info screen, "continue" will lead to a enter your mobile phone number (8 digits) screen. This one will be checked against a white list. The white list will contain the phone number, and the device ID (see below). If the phone number is in the list, then the device sends the device ID and can start working with the personalised blood sugar measurements.

iOS solution

  • Before iOS 6 developers were allowed to ask the devices about their UDID (unique device identifier). But because of the privacy apple does not allow this strategy any more. The applications that the device about UDID are dismissed right away.

Solution

  • Apple created another number to identify devices uniquely, the identifierForVendor. This number is unique for each device and each vendor. So even if the same application is installed in two different devices registered with the same apple ID, the identifierForVendor will be different.

Android device identifier

  • There is nothing like Apple's identifierForVendor.

Solution However, there is a solutions:

  • Android ID: a number created the first time the device is turned on. It is regenerated if the device is reseted to factory settings. Then it would be like a different device. But obviously, if you reset your device you loose all your blood sugar measurements so it doesn't matter if the application alerts your that you are going to replace your previous device and that you may loose all your measurements.
  • Google ID: I don't see it as an alternative because then we will not be a be able to distinguish two different devices own by the same user.