I have an app which is base in sqlite DBs and I need to create different versions of it. Each version is using different dbs, the name of them and the url to update them, and some other parameters but the code is develop to be the same in any version.
My question is how to do that keeping it simply. On android I have done several projects as library and I create a new project for each version. the new project is only a class extending from application in which I set the parameters for the name of the dbs and other strings which are defining the url etc. However in IOS I am not sure how to do that and having only one source to update for all versions.
I was reading a bit about targets but I am not sure if this is the best way, even I am not sure how to do it.
What do you recommend me? using targets? how to setup them to change the properties in the original project like the name of the database? Or do you have a better way to do that?
Every thing in the app to change the HMI or the content is in the DBs this is why I use different DBs for each version. Even I use the same DBs for the android versions.
Thanks for your help.
PS: just to clarify a bit more, the two versions has the same functions, it is just the content what is changed, and this content is in the DBs. I am not trying to have a pro and a lite version.
I think the different targets option is perfectly valid in this case, since you can decide which files go into which application. I have a similar app that shares most of the code but there are some specific resources that are specific for each application.
Just be sure that when you add new files to the project the correct target is selected, or if it's a shared resource, then all the targets are selected. You can do so in the utilities panel in XCode.
Related
I have an app which I will call it the "base app". The app works with many brands.
I need now to separate those brands, and to make a distinct app for every brand.
Every app will have a slightly different design (including different images) and here and there maybe some specific-to-a-brand code.
All of the apps should also use the same base code from the "base app" that deals with logic.
I have some options I have thought, but I am not sure if any of them suit my needs. Will be happy for clarifying the difference among the options.
The options I have thought are:
1) Creating an app for each one of the brands and just copy-paste the class files from the "base app" as a reference, except the .xib files, which will be copied as a copy. The problem is that then I do not know how and where to write a brand specific code (because it will be shared among others).
2) Creating a workspace that will include the projects for each one of the brand. Not sure how this works and if this is correct, will be glad for help clarifying here.
3) Nest a "base app" project inside every brand's project. Any help clarifying what does it do will be appreciated.
3) Using the base app as a static library which will be linked in every brand's project. Not sure what will happen with the UI (shared, not shared). Will be glad for help clarifying here too.
4) Using a simple way of maintaining each one of the brand's project, including the shared code (which will be a disaster, I guess).
The simple solution in iOS is use targets.
For resources you can use different targets for each brand and then select different resources (images, xibs, etc) for each target.
Also if the changes in code are minimal you can then refactor some part of your code and create different classes with different implementation for each target (you can use some pattern like a Factory). Also you can simply use preprocessor macros.
It's not the better, but this is the simplest and quick approach, but if your code changes a lot it's better to create a core library like the other answers say.
A good approach would be to split your app up into the following components:
Core Model Library
Reusable views & view controllers. The views can be designed to support skinning and customization.
Any other reusable code that can be encapsulated as its own 'identity'.
These core projects should ideally have their own continuous integration (quality control) builds and tests.
And then use CoocaPods
Instead of manually performing all this complex integration, use CocoaPods. CocoaPods will create the Xcode workspace, build the libraries and link them into your project. You then create a custom build just by gluing the pieces together.
In addition to this, CocoaPods also performs tasks such as:
Resolving transitive dependencies - which just means building and fetching any libraries that your libraries themselves use.
Managing versions of the libraries being integrated.
Private Spec Repo is possible, or just use GitHub
The main CocoaPods repository is of course public and contains open-source and/or freely available libraries.
You can host your own CocoaPods spec repository, or simply set up a private GitHub account, and include a PodSpec in each project, then resolve as follows:
pod 'MyLibraryName', :git => 'https://github.com/myOrgName/MyLibrary.git'
this will install all of your libraries into your workspace. To update your project to include any changes to the core libraries, simply:
pod update
Advantages of this approach
You'll have a separate set of quality controls that gets applied to each core project.
There'll be much less reputation.
You can use more automation. More automation equals less waste equals more customer value.
As the team grows, you can split up core product devlopment and solution integration into separate roles/teams. A team working on an integration build, need not pull the latest library features, if that would disrupt them.
You can have two different customers on different builds of the core library. CocoaPods will manage this seamlessly. So you wouldn't necessarily have to update a build, until you get an enhancement request or scheduled maintenance. (Again reducing waste, thus increasing customer value).
Inspired by Piggly Wiggly (but lean through and through)
This approach is modeled after the production line style approach that was popularized in Japan after World War II. Its called Lean Methodology, and is all about having a fast, small inventory and reducing waste. (Delivering more with less). . Japanese execs got the inspiration for this when they went to America and visited Piggly Wiggly Supermarket stores.
This is often something you encounter creating cheap flash-games or apps.
These have very generic frameworks like: kicking a ball, shooting at the screen, or generating a list with some data downloaded from a specific server etc...
Everytime they want to create a new shootergame, they just load up their shooting framework, add a bunch of graphics and can release a crappy game within a day.
How do they do it?
They often create a framework which contains shared models, handlers, interfaces etc.
Put a lot of general utility functions like downloading files etc in a library.
And you can also create some default framework views and view-controllers.
When you want to create a similar app, just import the library and re-use the base framework. Containing base-views, base-models etc.
You can find a good example in the demo-examples delivered with the ios SDK or android SDK.
Good luck.
I've created a web app (mvc4) that I'd like to reuse in multiple projects. The site is an admin panel, but it may be extended and slightly modified in each project. I want to avoid copying the project over, because I'd like to be able to update each project to the latest version at the lowest possible cost.
So far I have tried 2 approaches:
a script that 'clones' the project by copying all the necessary things as well as altering others (guids in assemblies, namespaces and things like that) - this works fine for extensibility and modification, but that's just a copy so pushing 'updates' is a mess (I did it manually) and it does not scale.
portable areas from mvc contrib project - this seemed like a good idea at first, but it turns out that it's nice for simple scenarios, but fails at more advanced use cases. It doesn't support localization (from resources embedded in the portable area), bundling and min requires a lot of hacks (mvc contrib is still on mvc 3), it's not possible (out of the box) to reuse shared views or Display/Editor templates from the portable area and it looks like if I'd go further that way, some new things would come up
Currently I'm thinking about 'just' branching each project from the core one. This would of course require the same changes (or at least a big subset of them) that were done in the script I mentioned earlier, and I'm afraid that if I try to pull updates from the core project the number of conflicts will render the whole approach unusable.
Does anyone have an idea on how I could tackle this problem?
I'd suggest to create a NuGet package of the mvc app and reuse it. So versioning and applying updates would be much easier. However it takes a bit work to make your code completely isolated from the codes you want to add in the new project.
Every application seems to start with me taking a similar app, thowing out the "meat" of it and using the skeleton for my new project.
I don't always get all that I want from a previous project, nor do I need everything from it, but certain things keep cropping up again and again:
about box (with contact email being generated from the app name & version number direct from the project options)
splash screen (source & duration)
only allow single copy to run
prevent task switching
acccept dropped files?
minimaize to tray
hide from task manager
recent files list
that sort of thing.
I used too have such a skeleton for C++ Builder, years ago. It just read an .INI file and customized the app's behaviour accordingly.
Before I take the trouble to port it to Delphi, does anyone know of anything similar which is freely available?
You can simply create your skeleton project and add it to the repository (IDE menu Project\Add to Repository).
If you want to be able to dynamically create different projects based on some parameters (user input) you can also write a wizard using the OpenTools API.
I'm a novice iOS developer with a basic knowledge of Xcode. I have one app in the app store that I made myself with Titanium. For a next project I've enlisted the help of two more experienced programmers in another city. I have a question in two parts about the collaboration between us:
I want to propose a work routine that gives me access to the project as they are working on it, so that I can device test builds during the development process - without interfering with the coding. What is the best way to do this? Is sharing the project or codebase via Dropbox an option? Does anybody have any experience with this?
Are there any pitfalls I should be aware of when pursuing this kind of work routine?
Thanks!
Use a source control system like Subversion, Git, Mercurial.
XCode has built in support for Subversion/Git.
Use source control. Github is a great place to start. (private repositories will cost money though.)
I used to use DropBox to share code between my two machines, but DropBox would routinely ruin work if I wasnt careful. DropBox is NOT version control. If you do insist in using Dropbox, don't open your code on more than one machine at once. Nuff said.
I'm starting to get to the point where I want to consider building a
lite version of my iPhone app. I've found a few things on the web that talk
about the process a bit, namely:
http://developer.apple.com/tools/XCode/XCodeprojects.html
http://www.pacificspirit.com/blog/2009/01/27/building_for_multiple_iphone_targets_in_xcode
What I'm
specifically interested in is simplifying the process of managing
which files are included in the different versions of my app as I
continually modify and enhance my paid for version.
Original answer is from the days before in app purchase. The correct answer now is to ship a single binary and offer your paid version through in app upgrades. It's slightly more code but it's a single shipment and your conversion rate will probably be better.
However, if you still want to versions of your app:
Xcode has good support for multiple targets.
From the project menu select "New Target...". Add another iPhone executable (Cocoa Touch Application) you can then specify on a resouce by resource basis which items are included in your target. This can include only compiling certain code into your paid version.
You can get quick visual feedback on what is and is not included in the current target by right clicking on the "Groups and Files" list header (top lhs) and enabling Target Membership.
You switch between building different targets in the same way as you switch between building for Simulator or iPhone.
To specify at build time how a specific class behaves you can do two things - include two versions of the class which are each built for their respective target or, you can set a build time flag for the pre-processor. Select the Target in the "Groups and Files" list then "get info" on that target. Go to the build tab and search for "preprocess". You should see a n item called "Preprocessor Macros" add LITE to your lite target and in the same way add PAID to your paid target.
Thein in your source files you can determine at compile time which version you are compiling for using #ifdef LITE etc.
Going even further, you could set a global flag or AppDelegate member variable based on #ifdef LITE and change behaviour at runtime for the Lite and paid apps. I'm not sure I see value in that though.
As a developer you want to write the least code possible (less bugs, less time). As the build versions diverge you will have to invest more work and separate tests.
Unless you are making an expensive hacker tool you might consider keeping the difference as simple as possible - just have some hidden preferences or settings. This way the majority of checks and tests will do the same work in both builds, very little code will be different. The key concern is not to burden yourself as a developer.
The reason to have divergent builds is to ensure that the Free cannot be hacked into a "Paid" version. The people who would try and circumvent such a simple limitation are primarily a sub set of those who would jailbreak their phones. No matter what you do you will not get their money under any condition other than they are so wowed they buy it just to show appreciation.
The creator of "Flower Garden" details the pros/cons of different approaches to creating a lite version here:
http://gamesfromwithin.com/from-full-to-lite-in-under-an-hour
With iPhone 3.0, you can use in-app purchases instead and allow that to unlock the full functionality without having to make more than one app. I also think that this will avoid people getting this for free, but I'm not as sure about that.
I used a git branch. I branched my main app and made a few tweaks to disable a bunch of content. Now i work mainly in the master branch and switch over to lite and merge in the latest when major developments occur. Works very well.
The better approach is to have just a single project, with multiple targets instead – one for each version of your app. So what are targets: Multiple Targets