New answers tagged ios
In the short term, I think it makes perfect sense to update the app and submit a new build as needed - especially if "bi-monthly" means "every two months". Eventually you will want to use a server. You'll have better control of the data, you can correct errors, update much more often, and you'll also know how often people use your app. Also, your users ...
I would suggest to cache them somehow and the simplest way to do it is to use NSURLCache. You can create a simple wrapper above it that conforms to e.x. <Cache> protocol, so you could change your cache provider without breaking any piece of code later. You can set up Apple's NSURLCache like this NSUInteger cacheSizeMemory = 5*1024*1024; // 5 MB ...
Load them all in again … but make use of caching more generally in your application. Now you don't have to worry about double-loading. Congratulations: you've just written your first "scalable" application. :)
A simple search gets you to Qt docs that tell you all about porting a Qt app to Android. As with most things, it depends - if you use features not supported by Android, then you'll have to do some porting. Otherwise, its generally easy. Also Qt Quick controls will take on the native UI style for Android 3+
LGPL and iOS applications don't mix well. For iPhone apps have to be statically linked together so everything must at the very least be LGPL. You cannot have parts be closed source.
You can use a protocol, like so: @protocol kObject - (instancetype) initWithKey: (NSString *) key; // I'm assuming the key is a string. - (void) send; - (void) processKey; @end However, it's uncommon in Objective-C for initializers to be declared in a protocol, and to enforce the LSP you would need to type any method or function that used one of these ...
Top 50 recent answers are included