I have a whole project developed under iOS which is a sales channel / ecommerce app which is a white branded product.
It mainly relies on a webapp but the native container handles a lot of features (session management, additional services, register to push notification) which is not only intented to make distribution on AppStore possible.
Thus, lot of code within the application delegate, use of several libraries through CocoaPods, etc.
Now, some of our customers whould love to integrate this ecommerce in their existing native apps, for instance, as a tab in a UITabBarController.
What is the best approach to do so ? Considering notably that both AppDelegate must be called, etc?
Thanks
I would advice to refactor your code and extract as much as possible to add it into your own Framework if you really want to keep it clean and have a good way of providing support to your customers. (refactor in a way so that it is easy to use for external projects, for example providing delegates/blocks in a matter that is straight-forward to implement).
A great starting point for learning how to create (Objective-C) iOS Frameworks can be found at https://github.com/jverkoey/iOS-Framework.
Any dependency (external library) you use for building the Framework will become a dependency for the project that will use your framework, unless you can add the source in your Framework.
Also take a look into providing documentation using Doxygen, AppleDoc, etc ;-)
Related
I am building a XCFramework for my company and the primary purpose is to expose our data for clients using this Framework. Clients can access data using this Framework through use-cases without knowing the implementation details.
This Framework needs a very high run-time maintenance support as we may have to add or update the use-cases based on clients requests or changing busing requirements. It's very important to design an automated solution to deploy new changes and make the updated Framework available for clients. I'm looking to host SDK somewhere so I can build and deploy it. Something like maven for Android. But I've not found some good solution yet.
I would love to hear if someone has similar experience or if someone can guide for a better solution. Thanks
I have been working on an app that uses Parse as its backend and while this works well, I don't want the app to become too dependent on Parse to work. Having the apps own Core Data implementation is probably the best way to go but the implementation must be flexible so that it can support syncing etc. I have been looking into frameworks like Ensembles, MagicalRecord, iOSDataManager and a number of others. I even looked at FTASync but this has not been updated for years and does not have a good reputation. I felt to ask the community what others may recommend as a good design of a backend system to sync with Parse or other web service. Particularly considering how important the backend is...
Thank you
I have used Ensembles, and I recommend it highly. The open source version is probably fine for your use, with the version 2 version available if you find you need any of the benefits for the paid upgrade.
If you want to see how to build a backend agnostic interface, then I also highly recommend studying the ensembles framework, especially how the interface for the cloud file system interface.
I have implemented my own backend for a specific project, and the interface is quite clear, and extremely useful for teaching one how to design and build such an interface.
How to go about designing a multi-platform app that offers In-App-Purchase?
I'm working with JUCE (Win/OSX/Lin/iOS/Andr).
I know that iOS allows IAP. So I'm guessing OSX also does. I would suspect Windows and Android also provide something similar. I doubt Linux provides anything as it is decentralised by nature.
So maybe I would have to write 4 separate IAP modules, and maintain 4 separate stores. Yuck! I don't want to do that. I recoil from duplication.
Is there any way to unify IAP across these different platforms?
The ideal solution would be single store to maintain, and a single C++ API to access it.
But is this even possible? I think Apple explicitly forbid any kind of store/monetising outside of their system. But http://soom.la/ seems to provide some work around for Unity3D.
The api will be same, but the platform specific functionality has to be separate. This way you have one repository and for a given platform build, pull the required code. Here is an example "Upload XML data to MySQL or NoSQL"
I co-run an RoR webapp that essentially runs in the same way as FML, TFLN, and all those "submit your secrets" apps from around 2009 work. Users submit "secrets" with tags as to what kind of secrets they are, admins approve them, then users can view them by tag or all at once, and comment on the ones that get published. Simple enough.
I'm new to mobile development, I've done some work in AppCelerator and Cordova Phonegap but that's about the extent of it. Recently I've been looking into RubyMotion (for iOS) and Ruboto (the Android clone) for application development. The applications I've made in the past have been small standalone 'egg timer tutorial' kind of things and I'm not sure what goes into making an executable application that has the same functionality and the same database as the webapp.
I've read on here that when you make an iOS app using Xcode, your RoR needs to be able to compile into Objective C before you can begin. Is the same true when using RubyMotion?
Where should I begin?
RubyMotion is quite enough different from Ruby on Rails. They have minimal resemblance in project structure, which will be a little familiar for RoR developer. Despite of injected TDD/BDD practices, RubyMotion has built-in weak test framework. Before you take full advantage of Ruby have to understand the principles of building applications for iOS/OS X platform, read a lot of Apple References (documentation), learn Objective-C as well. So easy start will not pass, as everyone expects from Rails. Most of time you will sort out Cocoa Touch/Cocoa API. And When you assume Cocoa philosophy, patterns, API you will be able to inject tasty Ruby features, like metaprogramming.
One more point is that in RubyMotion community dominates programmatical approach to build UI instead of XCode Interface Builder.
You can start with RubyMotion developer center. There you can find link to RubyMotion samples repository. And tons of Apple References of course.
I read several questions on programmers.stackexchange.com to determine if this question is better asked there. I think this question belongs on SO, but I'm not completely sure.
I have a basic knowledge of Objective-C and UIKit. I have read, a few years ago, most of Cocoa Programming for OS X (2nd Edition) by Aaron Hillegass; this is where the majority of my knowledge stems. The rest is from various sites, SO questions, the SDK documentation, and small personal projects (both OS X and iOS).
I am starting an iOS (specifically, iPhone) project for the university at which I work. This application will have distinct sections with distinct functionality. Some examples of "sections" would be: a virtual student ID card, current semester's class schedule (for the user), a campus map, etcetera. I want to be able to add new sections easily in future versions of the application. Thus, I want to design the project such that a section is an independent, from the main project, group of code (as much as possible).
In addition to being able to add new features by creating new modules, I want the project to be usable by more developers that just myself. That is, I want other developers on my team to be able to develop new modules for the application by following a "best practice."
Currently, I am basing my project around a UITabBarController with my "modules" being new UIViewControllers and NIBs. I get the feeling that this might not be an optimal way of establishing my project. Thus my question:
What are some best practices for such a project as I have described?
I think you're on the right track. UIViewControllers are a good way to break this up.
UITabBarControllers are often awkward when you have a lot of options; a welcome screen with a table view of possibilities might be more expandable. See, for example, Facebook's left panel or the built-in Settings app.
I typically find that the hard part about reuse in iOS projects is not the view controllers (which are typically well isolated) but the underlying infrastructure such as that for network requests, data storage, account management, etc. You might want to start with an existing framework for this (like, say, Parse or RestKit), or at least look at how they break things up.
On the topic of good, reusable iOS design, you might find Matt Gemmell's post about API design helpful, if not exactly what you're looking for.
establish conventions for coding style and resource location.
develop static libraries.
if your static libraries require their own resources (which can be a necessary pain), you may want to use bundles for your resources to minimize resource collisions.
centralize your build configuration files, rather than attempting to define each setting in each project (use xcconfigs).
then you can configure these libraries as dependencies in your app projects, and build, link, and copy appropriately.
one important note: i often err towards C and C++ symbols in these cases (where applicable) because ObjC symbols (and what they reference)cannot be stripped. this can reduce a lot of 'binary fat' where not used. so your 'core' libraries and libraries which deal mostly with symbols declared in other libraries (e.g. system libraries) may be in C and C++, and your higher level abstractions and derived types may be in ObjC.