Currently the app I am working on uses Bluetooth LE to communicate with a microcontroller which has a sensor on it and collects data by measurements.
Microcontroller has a set of parameters which are all configurable. Those measurement settings are configured by sending AT commands via Bluetooth and that can be done from different screens in the app.
When a measurement is finished, I need to store all the collected data somewhere as well as settings under which that measurement was executed. Different screens need to display this data and I am wondering what the best way to this is. I was thinking about having Measurement as a singleton and all of the screens would then read properties of an object of Measurement class and then display that data, but I do not like that approach.
I am wondering how to keep my code as clean as possible, separating responsibilites among different classes (for example BluetoothManager does not need to know about anything specific about the measurement or configuration of microcontroller themselves).
Generally, I would like to get some good advice on clean code in Swift, maybe some resources or tutorials which handle this in a project. An example project with a similar theme such as this one (CoreBluetooth, handling data that is needed across the app) would be great.
Related
We're looking to share AR experiences (ARWorldMap) over the web (not necessarily to devices nearby, I'm referring to data that can be stored to some server and then retrieved by another user).
Right now we're looking into ARWorldMap which is pretty awesome, but I think it only works on the same device AND with devices nearby. We want to be able to delete these constraints (and therefore save the experience over the web on some server) so that everyone else can automatically see 3D things with their devices (not necessarily at the same time) exactly where they were places.
Do you know if it's possible to send the archived data (ARWorldMap) to some server in some kind of format so that another user can later retrieve that data and load the AR experience on their device?
The ARWorldMap contains the feature points in the enviroment around the user. For example, the exact position and size of a table but including all the other points found by the camera. You can visualize those with the debugOptions.
It does not make sense to share those to a user that is not in the same room.
What you want to do is share the interactions between the users, eg when an object was placed or rotated.
This is something you would need to implement yourself anyway since ARWorldMap only contains anchors and features.
I can recommend Inside Swift Shot from last years WWDC as a starting point.
Yep technically it’s possible as according to docs here. You will have to use the nsssecure coding protocol, might have to extend if you aren’t using a swift backend though. It’s still possible as the arkit anchors are defined by a mix of point maps, rotational data , and image algos. Just implement portions of codable to JSON and voila it’s viable for most backends. Of course this is easier said then done.
I'm programming in iOS not so long. I was mainly programming UI related stuff like animations, custom UIControls etc.
I need in my new app to:
Display loading activity indicator and in the same time:
load some remote data from server parse them and store in local core data
load some data from local core data
get user position from location service
After this I have all data needed to display next view controller and dismiss loading indicator.
Question is how can I do this all? I need to support iOS9, iOS10, 11, 12. I understand that this needs to be done in background threads and then I need to merge all data from each task and switch to next view controller. I can't use any external libraries like rx-swift or promise-kit. Maybe there is any experienced iOS developer who can give me some main guidelines how to approach to this kind of application flows? I can imagine there is a lot of ways I can do it some of them are better and some of them are worse. Any guidelines would be very helpful for me. Thanks.
It's a very complex question and as you said it's possible to solve all this problems in several ways. But for sure i can give you some core-hints about which steps is better to follow:
Run in a separate thread the management of all stuff regarding to the Network communication. Maybe you can run it on a separate queue using the class DispatchQueue(). Once you received the data, in the same thread, maybe you can directly convert these information and store them inside a CoreData database.
To store into CoreData you need at first to know how it works, so basically search for some really easy tutorial about how to create from zero your first database inside XCode. After you have been able to run and execute a very simple one you will be able to pass to the second step and so try to integrate it with the data you have previously downloaded from the network. Here a good article for you: https://www.raywenderlich.com/7569-getting-started-with-core-data-tutorial .
To get the location is a separate field of study, because you have to study which background modes are allowed in iOS (And actually are allowed just a few). After that you will need to figure out in which category of background-location application your software belongs. After that you have to dig deep and discover how protocol and delegates works inside Swift/Objective-C in order to properly manage the last location value retrieved by the sensors. Here is a good article for you: https://www.raywenderlich.com/5247-core-location-tutorial-for-ios-tracking-visited-locations.
At the end when you interconnected all this flows you can think about how to display the loading indicator. Basically you need to drag and drop it from the tools into the storyboard, interconnect it by using the IBAction or IBOutlet, depending on when you wanna show it and in which specific case. And then use the relative method startAnimating or stopAnimating in the right code flow (It really depends on how you have structured all the previous bullet points).
Since your question was very general and it includes a lot of sub-steps, basically it really needs to be thorough studied and analysed.
I've tried to sum up as much as possible the most important bullet points. I hope the links i suggested to you will help a little bit. Good luck.
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 have been tasked with creating an iPhone application for a client.
I have some coding experience but only in C# so it doesn't really help here but other than that I am a complete novice on iPhone coding.
What I am trying to accomplish is to get some form of store locator on a map.
I have successfully added the map, get the user location with it zooming into the user. I have added 2 annotations (Which I believe the the best way to go about showing locations on the map).
I have 2 queries that I need help with, What is the best way to go about listing the stores in some form of database. XML, PList, .sql etc... (this would also need to be read from the web as it would need to be easily edited as new stores would be added a lot). Is it possible to loop through the database and dynamically add the stores onto the map within a location of the user?
I am not asking anyone to write any code for me, I am just asking for some help as I have googled the hell out of this and cant seem to find anything that helps.
Any help would be much appreciated,
Thanks
In terms of your potential formats for saving these locations, you options include:
XML/JSON are good formats for exchanging data with a remote server, but less ideal for a local database (though they theoretically could be used for that purpose). JSON is marginally easier to deal with (using NSJSONSerialization), but XML can be relatively easily parsed, too (using, for example, NSXMLParser). If you're doing network operations, I also heartily recommend looking at AFNetworking, which offers some nice advantages over the standard NSURLConnection. This, of course, presumes that you have written a web service on your server to deliver the necessary JSON or XML feed.
Plist is a fine, simple format if you want to save a short, local list of locations on iOS devices. Saving data to a plist is as simple as calling writeToFile method for your NSDictionary or NSArray and reading data is done via [NSDictionary dictionaryWithContentsOfFile:filename] or [NSArray arrayWithContentsOfFile:filename].
Core Data is a good, iOS-specific format for larger databases. It's probably the preferred iOS mechanism for dealing with persistent objects, but is an order of magnitude more complicated than plists.
SQLite is also a good database format if you're thinking about a structure that lends itself towards larger database, but also which lends itself towards eventual rollout to multiple platforms (e.g. both Android and iOS). If you decide to go SQLite route, consider an Objective-C wrapper (such as FMDB), which will simplify your life greatly.
Implicit in all of the above discussion is that, yes, you certainly can write code that iterates through your database and/or model data structures, extracting the necessary location information, and dynamically add annotations to your map. The Location Awareness Programming Guide should help introduce you to some of the MapKit related features.
"Is it possible to loop through the database and dynamically add the stores onto the map within a location of the user?"
Yes. Just as you have created those first two annotations, you now need to create more annotations in a loop. The only additional info you might need is that once you have added an annotation to the map it will stay there until you remove it. So you don't need to maintain your own list of annotations unless you want to do something else with it. Just fire and forget. So now your question comes down to how to loop through data from your chosen data source in Objective-C and not MapKit specific.
I know this is old but if anyone else comes across this like I did, you can use tmysqlkit by tanmay bakshi to read and write directly to a mysql database on a server.
Best,
Sam
I am writing an iPad app that will be expandable with new items via in-app purchasing. For example, my current plan is to have a jpg pattern and a matching plist file with the parameters I need to expand that pattern into a full picture.
The user will select one jpg/png from a list of small thumbnails - the list is held in Core Data - and the app will find the matching plist for displaying the jpg/png correctly. I'll only have about 10 of these open at one time. But I could end up with storing 1000s of jpgs and plists.
Does storage of lots of small files cause app problems?
I'm going the plist way, rather than storing the parameters in Core Data, so that if I need to add parameters later, I don't have to migrate the database, just change the access in code. (And when I'm creating the patterns, it's easier to concentrate on a plist file rather than a Core Data row.)
The app seems to work really well at the moment, but I'm worried about futures...
My app does also use Core Data for other things, so I could change over if the app will get bogged down with number of files.
Thanks.
Saving a large number of small files is not a problem as long as you have a well thought out means of naming and tracking the files.
Remember that the user does not have the same flexibility and ease of file management on a mobile as they do on non-mobile platforms. Designs that work on non-mobiles are unworkable on a device used on the move with one finger.
However, when you say:
And when I'm creating the patterns,
it's easier to concentrate on a plist
file rather than a Core Data row.
... the use of "row" suggest that you haven't fully grasped Core Data's utility. Core Data doesn't use rows, columns, tables or joins. It's an object graph management system that sometimes uses SQL way behind the scenes.
Core Data is designed to handle data in a way that meshes seamlessly with the rest of the object oriented API for the UI and other services. When you use other data management systems like plist, you will most likely end up manually duplicating a lot of Core Data's functionality anyway.