I have 2 Android apps that are 99% the same (different branding and a little bit of logic), so I have a library project that they both reference. This library project contains all of the UI and logic, and any differences between the apps are provided by overriding resources and extending my "LibraryApplication" (which itself extends Application).
I'm looking to port these apps to Windows Phone 8, and I'm wondering if there is a similar construct to help me mimic this pattern.
You can use Portable Class library for logic, however UI can't be shared in library. You can use files from the first project by adding them as a link to the second project. In case of UI it will be better to link all files without library at all.
Related
For applications like facebook, they provide SDK . I have used many third party libraries for different requirements. What is the difference between both the cases . That is the code bundled as library or as sdk
A Library is a chunk of code that you can call from your own code, to help you do things more quickly/easily. For example, a Bitmap Processing library will provide facilities for loading and manipulating bitmap images, saving you having to write all that code for yourself.
An SDK (software development kit) is a library (often with extra tool applications, data files and sample code) that aid you in developing code that uses a particular system (e.g. extension code for using features of an operating system (Windows SDK), drawing 3D graphics via a particular system (DirectX SDK), writing add-ins to extend other applications (Office SDK), or writing code to make a device like an Arduino or a mobile phone do what you want)
From this thread
Android SDK -> is the core features and software tools that allow you to create an app for the Android Platform. An SDK contains lots of libraries and tools which you will use to develop your application.
A Library -> is a collection of pre-built compiled code which you can use to extend your application's features. For example, you may need to show some graphics in your application. Instead of creating this from scratch, you may choose to use a pre-built library someone else has developed which will give you the features you need thus saving you some time.
Thanks to Nithish for this explanations
SDK is software development kit which provides a platform/a way to develop software while library project is a project which have some lines of code to solve any desire problem, it may have design or code files.
Generally library project focus only one problem but SDK is complete kit/tool to develop any task, if want some functionality in your code which is not present in SDK than we will go for any library project.
SDK is so that you can build applications for FaceBook. SDK can usually only be used in a more specific context. A library is so that you can take the library and use it on your own applications. A library is meant to be portable.
You can obviously use code from anywhere to anywhere, but I think thats the main difference.
There is a core ERP mobile application for Android. A customer has requested additional features that will require more screens (and Activities) and extra functionality.
Is there a way I can add sort of an extension to the core mobile application in order to intergrate the extra features or should I code on top of the code of the core application?
I am interested in finding a neat solution focused on extendability since different clients might ask for different additional features. How would you deal with such an issue? Any tips on the structure of such a project would also be welcome.
Would it make a difference if the extra features need to use the same db as the core application?
Thank you in advance for your help.
The answer to your question lies in the Open/Closed principle introduced by Bertrand Meyer. Open/Closed Principle is a very simple Object Oriented Design principle which states that
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"
From your question its clear that you have identified the core functionalities in your application. So rather than Modifying this core functionalities and making it more specific, I would recommend, on the basis of the Open/Closed principle, that you should freeze your code features and write your customer specific functionalities over it without corrupting the core.
Now to answer your question on what kind of structure you may follow. I would recommend that you create a library project of your core functionalities and make different client specific projects that would include your core functionalities as a library project.
It won't make a difference if your application is using the same db as your core application provided all your applications uses it, else it should not be in your core application in the first place.
Hope this explanation help you.
Update:
My friend pointed out that I may not have understood the question right. So rather than correcting my old post(...which may be useful for others) I am updating it.
So if I understand it right, you have an ERP project which you may not have coded. The right approach, according to me,still would be that you build over this existing code. Rather than making changes on this project, include it as a library because if the project is downloaded from a reliable source, you will have the benefit of getting the updated version as and when it is available.
This is kind of a design philosophy question. Here are a couple choices that might give you ideas:
You could look into making your core application code/features into a custom library. Then your new core application is just a simple wrapper that includes the custom library. Your additional features for a specific customer could then be a different app that also references the core library but will include additional features. There are lots of tutorials on how to turn your app into a custom library. You would end up with different apps that target different a customers. (A tip that took a while for me to uncover is that if you have a resource name in your custom library you can "override" it by using the same name in the app that includes the library. Another tip is that you need to essentially duplicate the manifest of the library in the app by listing all the activities in the library that would be used by the app.) I haven't tried this but it might be that your additional features are each libraries that are included in different apps.
You could have an key the user inputs that will unlock certain features. You could save this as a shared preference so that they don't need to keep entering the key. This approach has the benefit that you can "reuse" features for other clients without any more implementation other than determining which client gets what feature. The majority of users just wouldn't have a key to unlock anything.
Both these solutions should use the same db since they would be calling the same core classes, etc.
Another possible solution is to create a Library Project. Put your core ERP app code inside the library Project, and then create different project for different customers. Each one of these projects will also use the same library project.
Your core library project could expose an api to dynamically register new features (Such as a menu that can expose new menu items).
It's quite often that we see two versions of an android app: a paid version and a free version. I'm also developing an app that would like to release two versions. What is the best way to do this? Creating two projects and copying files in between does not seem to be the best way in my mind.
Use Library Project, as the official dev guide suggested:
If you have source code and resources that are common to multiple Android projects, you can move them to a library project so that it is easier to maintain across applications and versions. Here are some common scenarios in which you could make use of library projects:
If you are developing multiple related applications that use some of the same components, you move the redundant components out of their respective application projects and create a single, reuseable set of the same components in a library project.
If you are creating an application that exists in both free and paid versions. You move the part of the application that is common to both versions into a library project. The two dependent projects, with their different package names, will reference the library project and provide only the difference between the two application versions.
Update: This method is really only good for compiling with Eclipse, since Android Studio supports build flavors which can achieve exactly this.
While #yorkw's and #Nate's answers are both good, this is the method I use due to its simplicity. From the article:
com.example.myapp – Android Project Library - This is where my ENTIRE app lives. All the functionality for the FULL and LITE versions.
com.example.myapp.full - Android Application Project - This is a shell that contains graphics and resources needed for the full version only. Basically it’s a super lightweight shell.
com.example.myapp.lite - Android Application Project – This is another shell that contains nothing but graphics and resources needed for the lite version. Again, its a super lightweight shell.
I also keep a static variable IS_PRO in a library class which is set when the app launches. This should be used only for notifications, alerts, and so on (such as asking the user to upgrade to pro).
However, this method has one drawback: you must clean and rebuild any time the library or its resources are modified. Also be sure to read this post on sharing resources between a project and a library.
I would call this a FORK in development. Start a new App development, but have your common code coming from a common file location. Make your free based edits to the forked code, and try your best to keep that code completely separate.
I actually did this on an iPhone based app, I have a free version and 2 different payed versions (a single player only and a multi-player). I would do it the same way on Android.
U can use git for example.
Create branch "app_with_ads", and master will be your "paid" version.
Develop in master and merge periodically to another.
before publish u probably will have to change app package, or something else in Android\ Manifest.xml
Here's a little blog tutorial about doing this.
Basically a howto for building a Full and Lite version of the same app, using a library project to accomplish code reuse between the two versions.
We have a program that we wish to deploy across multiple devices.
Standalone Captive AIR
Web based flash app
iOS app
Android app
The code other than some UI stuff is identical in a lot of parts. I'm wondering what's the best approach. Should we have a shared library project or should we have one big project with different complier settings controlled through ant or some other method.
Accessing and using Shared Library Project is the best way to be implemented for cross platform Projects. Other than this Approach you can use ant Build.
The answer would ordinarily have a lot to do with the "UI stuff" that's different, but since it sounds like you're Flash/AIR, that's probably not a big concern. If it were me, I would go w/ the "one big project" approach, and get a serious CI/NI and SCM suite that was compatible w/ my IDE. If you're using Eclipse/Aptana, I like Husdon/Surround. (Full disclosure: I used to work # Seapine.) If you're not using Eclipse, you should check out the CI/SCM options that integrate w/ your IDE (and themselves; e.g., Hudson has a Surround module and vice versa). The shared library thing works, but since Flash is Flash darn near everywhere, I don't see the need for the increased division of separate projects. A full-featured CI can manage the compiler differences for you quite effectively.
We're using this combination of approaches for a large scale mobile/web project that currently exists in the IOS AppStore, and will soon be released on Android and the web:
One main project that uses compiler directives to handle specific platform logic and elements
Compiler directives to handle specific platform logic within the main project codebase
A separate project for our video and interactivity engine, which is mostly platform independent, using switch statements for platform specific logic
One shared SWC for graphical assets. Platform specific elements are prefixed with the platform and an underscore. Compiler directives are used to specify which movieclips get displayed on screen
Ant scripts to do the compiling for the various platforms
Native Extensions to interface with hardware specific features
We use some commercial, some open source, and some homemade ANE's for things like AppStore integration, social media features, network monitoring, notifications and inter-app communications.
com.adobe.extension.NetworkInfo.ane
com.milkmangames.extensions.EasyPush.ane
com.milkmangames.extensions.GoViral.ane
com.milkmangames.extensions.StoreKit.ane
(I have no affiliation with milkmangames)
I'm currently writing an Android ANE to handle inter-app communication using Intents. It's a project I'm open sourcing at:
https://github.com/interactivenyc/ANESampleProject.
I'm currently stuck on a problem there and will be posting a question very soon with the details if anyone is interested in following that project. The project setup is fairly well described in the ReadMe file displayed on the front page of the project.
If you use git for versioning take a look at submodules. I used it to keep everything in one project, but versioning each module separately, and it resulted a fine solution.
I'm fairly new to android and have only really been using eclipse for some basic Blackberry work so I was curious if I could pick a few expert's minds for any suggestions/pointers on the workspace/project setup you use for dual platform support projects in eclipse?
I've found about 80% of my code is common between Blackberry and Android so it's this 20% I'm needing to address.
My current thinking is to have one workspace with shared source in multiple projects via setting them in the source tree options.
Where platform specific features are used I'll tag the source name as *Android_???* and *Blackberry_???* respectively and have a generic class that both projects point to.
I.e. effectively one workspace holds both Android and Blackberry setups and in the workspace have one project for Blackberry and one for Android but each project shares the same filesystem with the appropritate other platform's source files excluded from the build.
If only there was an easy way of doing the #ifdef equivalent in java this would simplify this port but I guess we have to do it without.(I heard about using a c preprocessor to do this but sounds messy so unless it's highly recommended I'd rather not adopt this)
I'd heard about creating a shared library but have a feeling these are not compatible between android and blackberry so any advice on this approach is also welcome.
It's probably too late, but I'll still give you my thoughts on that.
I have a similar need. I have common code and Blackberry and Android specific parts. I have three separate Eclipse project for each part. The "specific" projects are the one actually run, and they both have a project dependancy (which I find cleaner than source inclusion) on the Common one.
Note that the Common project must be a Blackberry project (created using the plugin), since a Blackberry project cannot depend on a non-blackberry project.
It's working well for me!
For anyone else facing this issue I've found the solution that worked was by creating 3 directories on disk
Common
Blackberry
Android
The vast majority goes into Common however the classes that have platform specific calls go into the Blackberry/Android counterparts respectively and extend a common base class in the common directory.
E.g. a class called MyClass that needed platform specific versions would have a MyClassCommon in the common directory and in the Blackberry directory it has MyClass extends MyClassCommon definition and the same for Android.
In Eclipse the Common,Blackberry,Android src paths are individually added via a common variable (trunk) which is extened to the Common,Blackberry,Android paths for the 3 src root imports.
This seemed to be the only mechanism to ensure that the package name was consistent across platforms so not having a knock on effect that other dependent classes needed new package names.
I'm sure there is a more elegant/correct way of doing this but this appears to work well for now.