My ultimate goal: I want to automatically log my weight to healthkit on my phone every time I step on the scale.
Secondary goal: I don't want to spend much money, but I do want to learn. I'm a computer engineer and enjoy building hardware, but I don't just want to buy an off-the-shelf smart scale and install their app. Part of this comes down to data security: I don't like my information (especially health information) being in somebody else's hands.
Tertiary goal: I don't want to need an apple developer account (e.g., to roll my own on-phone app or something) but if I have to compromise here I will.
I want this to be as painless a process as possible - I've seen solutions that involve setting up a shortcut to ask for your current weight, etc, and I don't love that: less user interaction is better.
I'm usually wearing my apple watch when I weight myself, but might forget my phone (it's often right after a workout before I shower), if that helps.
I've seen a lot of questions on here talking about querying data, and I don't care about that: I'll use the phone to look at historical data, but I want to enter it automatically/painlessly so I have some data to look at.
For instance: I could set up an NFC sticker to open a shortcut, and maybe the process of scanning the sticker holds my phone in a specific place to read a QR code output by the scale? I honestly don't know if scanning a QR is possible in a shortcut, but this is just an example. The downside here is that I would need my phone on me.
The most promising solution from what I can tell is to build my scale to send the weight to google fit's API, and then install the google fit app on my phone to sync automatically. The downside is exposing my info to another service (google fit) rather than just keeping it in HealthKit, which I'd prefer.
Is there an auto-magic URL format that could trigger an iOS behavior to enter the data?
Is there an API through iCloud to just submit the data and not query it?
Is there a bluetooth option to talk to my watch and sync data there?
I see a lot of questions for querying/reading HealthKit data, but very little on submitting/saving it - so I'm not sure what's possible.
Suggestions appreciated!
Related
I want to begin a mobile app project for my college, i want to make use of flutter but am a beginner. The app is going to base on past questions of various departments of my college.
The questions will popping randomly with timer. How do i go about this?
I also need suggestion whether to make the app Online or Offline.
Making it Online, am thinking of getting the random questions from a rest API that outputs results in JSON but some of the users of the app might not be able to afford buying internet Data.
Making it Offline, i need how to go about this with Dart/Flutter. and also i'd like the size of the app not to be much as having questions stored in the app (Offline) might increase the size of the app.
I need suggestions on how to achieve my aims with Dart/Flutter please.
I'm still in the very early stages of a game, and I am saving information using a KeyChain wrapper class someone made. I wanted to ask for some advice early on, since I have time to change my approach.
My game has the potential to persist a fair amount of data about the player and what they've done, such as:
how much gold the player has
what items they've acquired (you can get about 50 items)
what skills, spells, and abilities they've chosen for their character
what experience level they are, max health, stats, etc
The reason I decided to store this in KeyChain was that I was told it's encrypted and much more difficult to tamper with. I felt there were other solutions such as the ones below, but I wrote some potential reasons why that might not be good:
Make everything web-based, and stored in a database somewhere on my server - I want my game to be playable offline
Use a local database (FMDB, let's say) - I could use a tool to edit the values directly, and give myself more health, etc.
Use Core Data - Never used this before, not sure if this is the same ease of tampering as #3?
GameCenter - Never used this before, so not sure what the lift is
NSPreferences - Preferences are more easily tampered with (i've used a tool to change the values pretty quickly)
So I am not sure if i'm completely wrong above, but let's say there is some degree of truth there and KeyChain is a good approach. The problem is now what if I want to then somehow allow the player to pick up a new device and pick up where they left off? How on earth would I serialize all that data I'm saving in keychain? I don't mind creating a giant JSON document of the values, and sending it along somewhere (where? to GameCenter?)
Any advice / pointers in the right direction would be good, especially now since i'm in the early stages and can make changes to step back.
Thanks so much everyone appreciate your time!
A few thoughts based on lessons learned (usually, "the hard way") that may (or may not) be helpful. :)
I see three requirements in your post: offline play (requiring local storage), data security (which is a massive topic in and of itself) and synchronization.
Playable offline:
Thus you need some sort of local storage. Keychain, Core Data, SQL, NSPreferences are all options. I don't know the limitations of the Keychain, so not really sure how suitable it is for continuous read/write of large chunks of data.
Data security:
They keychain protects your secrets when you're not logged in, and partitions them between apps. https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html and http://evgenii.com/blog/sharing-keychain-in-ios/ give more details. That should prevent other tools from modifying other app's content on non-jailbroken devices.
Core Data, SQL, et al will be inside your app's container, which makes it harder for other tools to access on non-jailbroken devices. There's a good description here: https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html
NSPreferences doesn't offer any security that I'm aware of. Plus, if they jailbreak the device, they basically have root access on a linux machine and can probably do anything they want.
In today's security world, the mantra is generally, "assume breach." As in, assume if they want in bad enough, they're going to find a way in. Thus you need to think about other layers of defense: partitioning your secrets so compromised secrets have limited value, encryption at rest and encryption in transit. Obfuscating the data before you write it/transmit is therefore another layer of defense (although they may still edit it and you'll have to handle potential garbage values).
You can chase security pretty far down the rabbit hole; you'll have to decide where the cost outweighs the benefit, and/or what risks you intend to defend against.
Synchronization across devices:
Thus you need a syncing solution. the iCloud Keychain syncs between devices, so if the keychain meets your storage needs, this probably will meet your sync needs, too. Again, I'm not sure if there are size or frequency-of-update constraints. I haven't used this, but this SO answer gives more info: https://stackoverflow.com/a/32606371/1641444. Based on Apple's docs (https://support.apple.com/en-us/HT204085) it looks like the user does have to enable syncing for this to work.
Otherwise, Apple provides GameCenter and CloudKit. Or you could explore 3rd party options. I've used GameCenter and CloudKit to sync data across devices. CloudKit wins over GameCenter, IMO, no contest.
With GameCenter, you gain multiplayer matchmaking and channels to share data between users. But, you have to adhere specifically to its structure which is IMO both extremely frustrating to work with and limited in functionality. Check the GameCenter and GKTurnBasedMatch tags here on SO for a taste of the problems.
CloudKit is a lower-level solution. It allows you to store a wide variety of data objects in iCloud and "subscribe" to change notifications. All data is contained within a container for the app, and has a "private" (user-specific) section and a public (shared by all users of the app) section. After watching the introductory WWDC videos on CloudKit, I was successfully sync'ing user settings between devices AND different users on different devices in no time. However, if you want some of the multiplayer features of GameCenter, you'll have to build the data model/subscriptions yourself. Since you support offline play, you'd need to save your data to a local storage solution and periodically upload it to iCloud for sync.
Conclusion (aka TL;DR)
So, my opinion is: none of the tools individually meet all three of your requirements, and you'll end up rolling your own solution for at least 1 req, regardless of which option you go for. In my multiplayer game, I'm trusting in Apple's filesystem (containers) to provide sufficient data security, I'm using a local storage option within the app's container, and I'm periodically writing NSData objects to cloudKit for synchronization across devices. I hit my frustration limit with GameCenter and pulled it from my app.
Star for a good question!!
I'm doing something similar with this. Right now, I'm using UserDefaults for primary storage. When I need to transfer data, I can save it to iCloudKit, or I could export it as a plist or json to use with AlamoFire, email, etc.
As for actually storing the data, I saw you mentioned CoreData.. that is kind of overkill! Look at NSCoder and NSKeyedArchiver.
Personally, I make my own save/load functions that manipulate dictionaries, then toss them into a UserDefaults key.
An example hierarchy of how I store dicts in UserDefaults (there are many ways to go about this)
Key:
Items->Equipment->Weapons->WeaponName
Value:
{ dictionary of data like AP, Cost, etc }
This to me is easier than using NSCoder, and certainly easier than CoreData!! The goal is to turn everything into a dictionary, which you can then easily put into UserDefaults, which allows you to easily create plists or save to the cloud.
With the above key system, you basically just do for loops to find what you need, parsing out each section.. so a function to display all equipment, you just load the entire UserDefaults.standard.dictionaryRepresentation, then search for keys that only have 'Items->Equipment' and so on.
Hope this helps!
I have some functions from my game I could share if you need more tips.
UPDATE:
If you are making this an online game, I would focus on learning the essentials of persistence and cloud usage first, then port it to a more secure platform that uses encryption.
Your best bet will be to create your own servers and transfer data that way. That will give you exactly what you want, when you want it, and with the security that you want.
If you want to use GameCenter, I would use GC as an in-between layer of something custom you created, so that way you can filter out the cheaters' scores / have more flexibility.
I'm a complete noob at Swift (and Xcode), as a matter of fact, the only programming language I (somewhat) know is Javascript.
I'm trying to make a Swift SpriteKit game, and I would like to access the number of calories burned in HealthKit.
The idea is that my game will provide more points the more calories you burn using other apps like Endomondo. My app does not actually track anything, I would just like to access other data left by other apps in the Health App.
Is this even possible? (I'm running the latest version of everything, from Mac OS X to Xcode)
Certainly. I don't think there is anything technically preventing you from making calls to the HealthKit APIs in your game. In fact, you're fairly free to mix and match the use of any public frameworks provided on iOS.
One thing to keep in mind is privacy and disclosure of the use of health data. The user will have to explicitly grant your app permission to see data.
HealthKit is a really rich API with lots of ways to access lots of different kinds of data, and you're really only interested in a small part right now, so a quick way to experiment is to create a new Swift SpriteKit game from the new project template in Xcode, do your research on HealthKit, and see if you can just log the number of calories burned since some time point while your app is running. If you can do that, the rest is details (as in, the entire app :-)).
Here are what I think might be some helpful links, good luck on your project!
https://itunes.apple.com/us/book/swift-programming-language/id881256329?mt=11
https://developer.apple.com/library/ios/documentation/HealthKit/Reference/HealthKit_Framework/index.html
You'll also find some good documentation on SpriteKit (references and guides) on the iOS Developer Library site.
I'm currently looking for a way to track basic user data for mobile iOS application:
how many times the app was launched
what was the average/by session time spent in total while using app
what was the average/by session time spent on particular screen
Additionally, I'd like the solution to:
display a heatmaps or click/tap/maps (clickstreams), to show how users tried to interact with the interface
generate visit graphs (user started from this screen, then went to this screen, etc.)
The most important requirement is that this is for internal application testing (nothing malicious), and we want to categorize data by user logged in (so that we can gather data per user, not some general average).
Can anyone recommend a suitable tool? Price or paid, doesn't matter. Is Google Analytics up for the job, or do we need something else?
Youve got several options to track the user behavior in the app. You can use frameworks like :
Flurry (http://www.flurry.com/)
Mixpanel (http://mixpanel.com/)
Localytics (http://www.localytics.com/)
Google analytics
Im pretty sure there are more. Flurry is free (for now but you have some special paid features) and it´s broadly used. It´s the framework I use the most for my apps in these moments but it will depend of the client and the information you want to track. You can track events, events with information, see the stats of use, how the user has used the application, find dead holes in your app and broadly speaking, have a general idea about how your application has been used. The other frameworks are not free and you have to pay for the services but you can always use a trial version to see if this is what you want or not. Ive used localytics and its nice.
Ive tried all of them, and there are pros and cons, but to get a general idea about your application, everyone serves. Regarding heatmaps, Im not sure about that, I mean if some of the frameworks offer a solution like that, but you can always build your reports with the provided information (I know it´s not a straightforward thing or a 5 minutes thing).
Take a look, compare and decide which one can fit the best for you.
Well these days app analysis is very important and are of great help. There are large number of analytics tools available. Some of them are free some of them are paid.
below are some of them
Flurry
Google Analytics
Heatmaps
These are few which are used most. For most list visit this link
Hope this will help you. happy coding :)
I have a Rails 3 app that I'm looking to create in-house analytics for. The items I need to track are impressions (and unique impressions), clicks that come from those impressions, and conversions that come from those clicks. And these are all user-specific so each user can see how many impressions, clicks, and conversions they've received.
What is the best way to go about this? Should I create a separate rails app and call it with pixels? Or should I include all the analytics code in the same app?
Also, are there any analytics platforms already out there that I can customize to meet my needs?
Thanks!
Tim
Before you start re-inventing the wheel, Google Analytics provide a developer API (via OAuth, among other choices) that may provide you with the ability to do what you need (provide each user with a view of their own data).
http://code.google.com/apis/analytics/docs/gdata/home.html
Building your own, while it may seem like an initially basic thing to do, could have serious performance implications further down the line, and Google provide a very detailed view of the the data.
If you really want to write your own, I would strongly urge you not to hit the database for each request you want to track. Keep the data in Redis, or one of the alternatives and periodically persist it to the database via a background task.
If, however, you don't want to put your data into the clutches of our Google Overlord :) then you might indeed consider rolling your own. I have twice before - and I'm doing it again right now: better this time, of course!
If your traffic is not very high and you're running on any decent server platform then adding a tracking system is not going to tax your Rails app noticeably (I know that depends on what 'decent server platform' means but this stuff is pretty cheap these days). Writing to a database is typically very fast - you'd have to have shedloads of clicks to not want to do this straightaway. You can probably bypass most if not all of your before_filters and so on to get a lightning response. One app that runs 2.3.9 uses Metal to do this, for example.
In my new tracking system I have an STI table that goes with models derived from an Activity model; in here you can record both impressions and clicks. Impressions are recorded as the page is built and clicks are recorded using AJAX.
I'm not going to bother with fancy graphs and so on - I'm happy with raw numbers - but these could be added, of course.
At the moment my system is just in the usual app/ folder but I'll probably move it to an engine so I can re-use it more easily.
Hope that helps!
BTW I use Google Analytics as well for a range of sites and it's OK - I just like to do this bit myself.
Depending on how you are going to associate Google Analytics data with a specific user then you might need to double-check the privacy implications. Google doesn't allow their data to be associated with any identifying information about the users being tracked.
If there is a problem then you could try out Piwik as it's open source and you can do what you like with it. It's written in PHP, not Ruby so that might be an issue. As #d11wtq mentions, tracking systems can have performance issues if not built in the right way so you'd be better off starting from something that's already proven to work if possible.