I am currently making a SDK that would require fetching data in the background. For an example, let's say that the SDK provides some weather data that needs to be relatively fresh to be useful. At some point, the data is outdated and needs to be refreshed. The problem is, that the app might be often used in places with poor internet connection, or with no internet access at all. This brings me to the idea that maybe I should fetch the data in background, when the internet is accessible.
The SDK is packaged into a XCFramework, and distributed using Swift Package Manager. When I try adding capabilities to my target, Xcodes gives me a screen that states "No matches, Capabilities are not supported for SDK".
Is it even possible to make a background data fetch without the access to app capabilities? Or does this responsibility fall to the client app for my SDK? Sorry if the answer is obvious, I've tried searching online for a direct response to my problem, and wasn't able to find a clear answer.
An SDK/framework can't request such capabilities, but it can contain the code necessary to do all the work. You need to expose a function that the client can call to run this code.
E.g.
Inside your framework
public func setupBackgroundDataFetching() {
// create background task
}
Then inside your README, you need to tell users that they have to enable this capability and call:
let weatherSDK = WeatherSDK()
weatherSDK.setupBackgroundDataFetching()
Inside their AppDelegate. Depending on your use case you may need to have the function take in some parameters, or make a singleton class and have this as a static/class func, etc. But the basic idea is the same, wrap up the code and ask the client to invoke it
Example:
Heres the repo of a crash reporting tool I use: https://github.com/getsentry/sentry-cocoa
You'll notice their README contains installation/usage guide which asks users to run a setup method in their AppDelegate, which takes in a configuration. Based on this configuration, they can setup anything they need once the app starts, such as a background task if needed
Related
I can't seem to locate a built in mechanism to store user settings. I was hoping that electron provided a standard method for storing user settings across all desktop platforms. If there isn't a precedent for this I can implement it myself, I just didn't want to jump to a custom solution immediately. Research online is pretty sparse in this area. Thanks!
Each platform has different default locations for different kinds of data. So, if you want to store data in default locations based on platform, check out app.getPath(name)
It retrieves a path to a special directory or file associated with name.
You can also use it to differentiate between data the user wants to save, and data your application saves that you don't want to clutter up users directories.
Or if you just want to store files reletive to a specific path you can use the
app.setPath(name,path)
I've faced this particular problem with my Electron app and this post inspired me to write an NPM module called electron-json-storage.
This module allows to easily write/read JSON to/from app.getPath('userData'):
const storage = require('electron-json-storage');
// Write
storage.set('foobar', { foo: 'bar' }).then(function() {
// Read
storage.get('foobar').then(function(object) {
console.log(object.foo);
// will print "bar"
});
});
Electron doesn't give you anything out of the box for this. However, Electron does give you a method for getting the idiomatic location of storing user data in a cross platform way via the app.getPath API.
I'd say the 3 most common ways to do this are:
localStorage (or any HTML5 storage API)
flat JSON file (this is what I do, and I use electron-store for it)
embedded database like IndexedDB, neDB, or sqlite
Which one you choose will depend on your app's needs. If you only need to access this data in the renderer process, then I'd just use localStorage. Most of the time it seems you need to access the data in both the main and renderer, so a JSON file makes sense. If you're dealing with lots of data or complex querying, then maybe a database makes sense. I wrote about this more in detail here.
How about LocalStorage? If you need to access these settings from the browser process, you probably need to write your own (or just use a node.js library that implements this)
The best way that I have found is to store it in a simple file as JSON. The problem is that if you store that JSON in the app dir, then when you update the app, it will get wiped out. So you want to put it in the default directory for user settings for the current operating system. LUCKILY!!!!! There is a library for node developers that will help you find the userdata directory. The module is called appdirectory, and I have used it several times. It is extremely easy to use.
See APPDIRECTORY HERE
One could store data in cookies; Electron has a mechanism for it (https://electronjs.org/docs/api/cookies) and the cookies can be retrieved in the browser (Angular: https://docs.angularjs.org/api/ngCookies/service/$cookies, React/Other: https://github.com/reactivestack/cookies)
I was able to get it working with Angularjs.
I would like to sync a core data app with a user with a different iCloud ID and I am trying to figure out the most graceful way to do this. I do not want the data to sync with all users, but want to be able to sync among family members for instance. From the research I have done, I do not think I can do that using iCloud Core Data sync because it only syncs between devices with the same iCloud ID. I have looked at this stackoverflow answer and read a little bit about Ensembles, Parcelkit and TICoreDataSync, Parse etc., but it is not clear to me if any of those options will allow me to sync with multiple users. Does anyone have a good method for syncing a Core Data app with multiple users?
Ensembles and TiCoreDataSync might work. They can use Dropbox file syncing, so in principle they should work with Dropbox shared folders. I don't think these are the main intended uses, so I suggest contacting the developers and/or doing some good testing yourself before assuming this would actually work.
You'll need to think about the user experience, though. At a minimum, your users would both need Dropbox accounts and would have to set up a shared folder before beginning to sync data this way.
Parcelkit probably won't work. It uses Dropbox's data store API which, unlike other Dropbox services, doesn't appear to support shared data.
Services that do support this kind of sharing exist-- for example, Parse and Firebase-- but make sure to review their pricing carefully before using them. Also of course, there have been any number of projects that have their own custom server back end, but that obviously requires having someone on the team who can do that kind of work.
You need to think about other device types (Android at least) if you want your application to be reaching more users.
I'm doing the same now by the following way:
Setup an online database with proper web services (careful with implementation for security matters - DB should NEVER be exposed by anything other than the web services).
Create a Class for your communication with the server (using Class methods with security handling like authentication and authorisation).
Use the class in your app to communicate with the server (SQL operations are done on the server).
To integrate with CoreData you need to create the model in your app similar to the structure in the backend database. Then you need to create a similar class for the app that deals with only local CoreData.
A higher level class might be required if you want to make sure that operations done on both server and local data storage.
Besides, you have to implement a lot of conditions to make sure that data written in local ONLY after making sure that it is stored online (or create an engine for differed operations to run later).
Another Way if you are familiar with notifications:
Use structured notifications between devices for data operations in order to keep everything in sync with other users. The problem with this is the "Autonomy" of the operations. If two operations were done in approximately the same time, you have to find a way to make sure the order of the operations is done properly (maybe timestamp or something).
I'm looking into the same thing for my app and I 'think' you can do a fairly unsecured version of what you are after using using the public folder in cloud kit as mentioned in this question (no accepted answer at time of posting) : Private data sharing using CloudKit
You would need to find a way to differentiate between data that is truly public and those shared among the users you need and some level of authentication.
I'm going to try exporting a permission file with access permission in it to whomever I want to share with combined with a unique identifier located in that permission file.
Keep in mind, as mentioned in the comments of the linked answer, my implementation will be security by obscurity (thanks for that phrase) unless you find a way of adding proper validation to it but my data is relatively insensitive.
Hope this, or any ridicule in the comments, points you in the right direction : )
I have the application that will connect to different servers. Each server is like different client and I want my app to look different (as far as I can) depending on which server it is connected to. I thought that I can have a ZIP that on handshake will be returned from destination server and use details from it e.g. Images, settings etc.
Is it possible, if so what is the limit?
Edit
I'm thinking about the images for logo etc. and some color lists that I can then use with fallback to defaults.
You can make all resources (images, string files, NIBs, storyboard...) be downloaded from the client server.
Also, there are several project developed exactly for dynamic design using CSS-like mechanisms:
http://www.pixate.com
http://www.freestyle.org
https://github.com/robertwijas/UISS
https://github.com/tombenner/nui
There are some project to run Javascript as well. This may allow you customise some business logic.
http://www.bignerdranch.com/blog/javascriptcore-example/
https://github.com/kishikawakatsumi/JavaScriptBridge
So, yes. It's possible, but you'll find some limitation, like the root view controller, the app delegate, etc.. You'll have to be creative.
I've never done something similar, so I can help any further then this.
It's possible for almost all elements of the application except:
Application name
Application icons
Application splash
screens
Those 3 items are bundled into application and can't be changed in runtime.
Rest of the items have so called appearance selectors that can be used to implement dynamic branding.
It is definitely possible, as I have worked on an App like this myself. We did it basically the same way you described. On startup the user selects a server to connect to and we download a zip file that contains all the assets for that client. After the download, the UI is loaded with the custom images. You can customize any UI element the system lets you, which is pretty much everything, except for minor details like the system StatusBar. You're gonna need some helper classes that make your life easier and support methods like, for example, [UIButton themedButtonWithImage:].
Well, it's possible — in one extreme, you could have an app which consists entirely of a UIWebView (plus some mechanism for selecting which server the app is talking to) that gets almost all it's content from the server.
There are performance considerations if you do (internet connection reliability, cost, and speed), and Apple may object to certain things being done on any app distributed through the app store, but assuming you follow their guidelines or distribute outside the store, the only limits that I know of are the app icon, the startup screen, and the app identifier, which have to be included in the bundle.
I am going to develop an iOS app for a web application. (The web app uses code igniter)
I am going to create an API Service that the iOS app will consume.
I am thinking of creating an api version, so when the web api changes, the iOS app will know.
Concerns:
iOS app will need to be updated when web application api changes (unless I keep legacy api available..Is this a good option)
If iOS app is updated when web app api is NOT updated this will cause a problem too
Should my iOS app specify the version of the api it requires?
If iOS app api is less than web api: Display Message: Please update iOS app
If iOS app api is greater than web api: Display Message: Please update web app
Is this best practice?
Should I make an api class for every version and extend the previous version and override methods when they change?
Example
ApiV1 extends CI_Controller
{
function list_customers(){//Code}
function saveSale() {//Code}
}
ApiV2 extends ApiV1
{
function saveSale()
{
//New way of saving sale
}
}
Also what happens if I make a change to the database structure where the v1 api will no longer work? (Example, changed the name of a database table?)
In general, you want to create a fairly loose coupling between your service API and your client. As a rule, there will be multiple versions of the client always floating around in the wild, and you want to force upgrades on users as rarely as possible.
A full rev of an API version is actually somewhat rare in web services, and usually only corresponds to significant changes to the data model, security model, etc. Allowing multiple versions to coexist may require some extra work on the service, but can be worth it to allow existing clients to keep working.
To that end, think carefully in the design up front about the "model" you're using as an abstract entity independent of the current client UI needs. (If you want more specific thinking around your particular case, you may wish to post a separate question about modeling your needs.) But don't worry too much about solving all of the needs forever in advance, because requirements will inevitably change.
Once you've done this, do prepare for the future by building some notion of versioning into the service API. Some things to consider:
An explicit version as part of the URL scheme or specified initially during e.g. auth handshake. This is a way to cleanly namespacing what the client accesses. (The former would result in explicit URL routing on the service, the latter would require more gymnastics to route after cracking an auth token.)
A known error response that means "this API call is obsolete", which an earlier client can recognize to tell the user that their client requires an update
On the service, your design can be as explicit as you note, with a controller with method overrides, but at a little higher level: the saveSale method is somewhat unlikely to behave very differently between versions. It would seem more likely to have a saveSale method in V1 that does the baseline thing, and then maybe e.g. saves some extra bit of data in V2. When that happens, the code might just have conditional branching if that extra bit of data is present. All of this is another way of saying that a service API doesn't actually change incompatibly that often. list_customers could return more information over time. That doesn't necessarily mean that your API needs a new version or that old clients shouldn't just ignore any extra information they don't need.
Re: your final question about database table names. Those may change internally, but you aren't required to map those explicitly to what the client sees. An API is a stable interface that should ideally hide the implementation details of your ever-evolving service.
You'll choose to rev the API when, as a whole, you decide that the overall picture of what the API needs to do is significantly changed enough that it cannot peacefully serve the needs of existing clients. You'll choose to deprecate and obsolete certain client versions when you decide that maintaining support for them on the service is causing you more headache than the install base is worth (a very business/case specific issue).
Good luck.
I don't know if having your iOS app specify the version of the api it requires is good practice but, I would think it is a safe play; one concern though, if you frequently update your api then it won't be long before it becomes a hassle/anoying having to frequently update the app.
I would keep legacy method name(s) and add method(s) with a different name to avoid users having to update to new version of the app when you change the web api.
I would not create an api class for every version to extend the previous version of the api.
I would say changing the database structure would require changing/updating your api, unless you also want to keep legacy version of your table name or definition or data, which it is not feasible/practical/convenient in most instances/situations. In this case you want your users to update to the new app and api.
Look at this answer that points to a presentation of API design principles and practices.
I do not know as to what best practice, however I would definitely recommend that your iOS app keep track of what version of your API it is looking for, and specifically request that version. For instance, a URL of '/api/v1/....'. This way When you update your API, you can simply up it to a different version ('/api/v2/...', and leave v1 alone for the iOS app to consume. Obviously you should display a message to the iOS user to upgrade (perhaps a meta field in your response) when a newer version exists.
This approach should allow you to continue development on your API without cutting off people who haven't been able to upgrade their app.
Update
Just one more thing; if you make a change that will make a previous version inoperable (such as changing table names, schema, etc), you should have a status code for that that your iOS app will understand. Something associated with the message 'This API version has been retired. You must update'.
I would also recommend a similar header (or something) when an API is deprecated (ie, a new version exists). Obviously continue to provided the requested information/actions, however a warning that the version is not supported anymore and that they should upgrade (or even triggering something in your app to upgrade) can be helpful.
I need to add a User Manual for my App, although all the user manual examples I have seen are web-based, which is convienent because it allows you to update the documentation without updating the app but also inconvient if the user is in a off-line mode.
What I envision in a helpful usermanual would be a popovercontroller that would display relevant data to whatever the current view has. It would retrieve documentation from the web and save it for later reference. Maybe even something that could take a document and break it into a plist by tag. Including gaphics would be nice also.
Are there any frameworks do to this available? ..... Or am I going to have to write my own.
How have other people implemented user manuals?