Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have an app that has about 10 different components (chat, feed, profile, settings, etc').
I need the ability to create multiple apps that each one of them will have a number of the components.
example:
app1 - will have chat settings and profile.
app2 - will have feed and settings.
How should i approach this?
I was thinking of building each component as a library and then for each app that i need to build a just connect the pieces like a puzzle.
Would this be the correct way? Or does anyone have any better suggestions?
Thanks
You can develop an "SDK" project (like the Facebook SDK) which includes all the components (chat, feeds, profiles, users etc.) and you can use that "SDK" as a library in other projects. Use whichever components you want for that particular app.
This approach will make the "SDK" project maintainable and easily upgradable. When you are adding a new feature (say, albums) you can integrate it into the "SDK" project and use with the existing applications.
An extensible, modular design of this sort is often quite useful for building larger scale software or software designed to handle a wide range of unanticipated future needs, especially if you're mixing in bottom-up approaches.
However, effective ways to approach this vary somewhat depending on the language and tools you are using.
An awkward part is how to make modules able to talk to each other when needed so that you can effectively piece them together like lego blocks. This will often become a practical need as the complexity of your software grows to a point where it will often cease to suffice to simply have modules completely decoupled from each other as stranded islands and only one "master" module to communicate with all of them. Often your needs will grow to require them to start talking to each other.
For example, if you are using a dynamic scripting language like Python, then it's easy for each module to publish its own public interface and you can start making modules talk to each other that way almost effortlessly.
If you are using a compiler and statically-typed language like C or C++, then this becomes a lot more awkward to make each module publish its own unique interface which is being directly imported and used by others. There you face the need to make headers accessible to all modules, worry about preserving ABI as you make changes, etc. A larger number of changes will break ABI and break other modules depending on a particular one's interface, so there we tend to design a bit differently.
In such cases, you almost always want a central software development kit containing all the abstract interfaces. Then your modules implement those interfaces and still communicate with each other, albeit indirectly (plugin A talks to SDK interface which is indirectly communicating with another plugin, B). The SDK establishes that central headquarters of communication, relaying messages from one module to another.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I develop an app for both iOS and Android, and I'm loon'ing for the best way to share code between this two platforms.
What I would like to do is creating all the View (UI part) in native but share the code for the logic (controller + model).
With all I found, 3 things seems to be quite good :
1) C++ --> Build library file Using c++ For the logic so I'll be able To use the .dll files in the 2 platforms
2) Azure mobile apps services. Is it possible to habe all the logic in a webservice? The issue is that if I dont have acces to internet, my app will be unaivalable, right?
3) I hear a lot about React native used by Facebook, but it seems to be used to create the UI, but I prever create it in native. Can I use react only for logic?
It seems like you have three options:
1. C++
You can't just have a compiled .dll and expect it to work for iOS and Android. They both have to be compiled in different architectures and it has to be a static library on iOS.
Dropbox's done it this way, and they've put up a lot of notes and example code, and code you can use so you can take a look.
Pros
• Pretty straightforward after you manage to set it up
• No additional layer of dependencies, bugs, etc (like in case of Xamarin/React Native)
Cons
• Setting it up and using it needs a lot of extra work: you need to setup additional compile steps and write wrappers for both platforms.
• Some other challenges you're surely going to meet when trying to compile the same code for two different architectures
Here's a SO post on how to do it in detail...
2. Xamarin
This option seems to extreme to use in this case. You're forced to use C# and introduce another layer of dependencies and bugs. You said you don't want to use another language for UI so I wouldn't recommend it.
3. React Native
Now this is a viable option. You can write scripts in JS and use them in native code in both Android and iOS.
Here's an article on how to share code with code examples...
Unfortunately it uses React Native for UI, but you can easily call React Native functions from native code.
There are a lot of downfalls to using this, including the fact that the calls are asynchronous as they're executed on another thread, so you would have to implement some kind of callback system for functions that return something.
Pros
• Seems to be easy to set up and write
Cons
• You'd have to implement a native callback for every function that returns something
• Using it has a lot of downfalls that the document describes:
• As events can be sent from anywhere, they can introduce
spaghetti-style dependencies into your project.
• Events share namespace, which means that you may encounter some name
collisions. Collisions will not be detected statically, what makes
them hard to debug.
• If you use several instances of the same React Native component and
you want to distinguish them from the perspective of your event,
you'll likely need to introduce some kind of identifiers and pass them
along with events (you can use the native view's reactTag as an
identifier).
Conclusion
I think I'd go with C++, mainly because a big company (Dropbox) tried it and succeeded and actually uses it in production. You could try React Native as an experiment, it would make a great study case!
I'd say that putting the "core" logic into a separate library is a sensible approach.
You are not the first who wants to do this, and I highly recommend looking at Djinni. It's a tool to accomplish just that. You can define common interfaces and datatypes and fill in the native parts. Communication is possible in both ways.
It's not as easy as writing the whole thing natively at once, but it supports clean design which you might benefit from anyway.
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).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
:) When you write a iOS App, in order to use the UI like buttons. you have to write it in Objective-C. (Java on Android). I was wondering if anyone had any thoughts on the technical reasoning behind this. Why they might of done this. As you can write apps in C++ on iOS so I've never fully worked out why they didn't expose a way of making the UI in that. (Ignoring the fact that this is how they did it on the Mac).
Note: I know you can write apps in c++ for Android but the question is more why is the main UI i.e buttons etc forced to be written in a dynamic language for these platforms, why not expose access to it thorough C++ without having to write a crude wrapper or binding layer yourself.
I'm guessing that when the original framework engineers were working on their respective operating systems, cross-platform desires like UI support in a different language like C++ was at the bottom of their concerns. You'll have to realize that when deadlines loom, all of the features are prioritized only what is considered most important is made to work. Everything else is a consequence of that.
In the case of iOS, Objective-C is the language of choice for the OS that Apple uses. All of the MacOS app developers were writing in Objective-C so their developer based was in familiar territory.
In the case of Android, Java was already a popular language, with existing open source tooling and libraries (Eclipse IDE, Apache Harmony), so presumably they decided to use Java as the first class language for app development with apps running in a VM as a consequence. Alternatively the decision may have been VM first for the sandboxing of apps and Java was picked as the language for app developers. Or some other reason.
In either case any attempt to add in additional languages now that both are in the hands of customers means design decisions and trade offs along with a host of other questions like: how to add it in without breaking existing APIs, how to support it along with new features, how to test, etc. etc.
As you see more and more software, you'll realize that lots of stuff is just arbitrary or made sense at the moment of when it was designed.
iOS does expose a C API for drawing UI components; it's called Core Graphics.
Because the view itself is written in Objective-C, or Java, respectively. When in Rome, do as the Romans do.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We would like to develop an application that runs on both iOS and Android. We cannot come to a decision however whether it is better to first create the application on one platform and once we are satisfied, replicate it on the other, or finalize UX decisions in the beginning and develop the platforms in parallel.
The application is simple and we have the resources for developing it. It is just a question of whether to develop the platforms sequentially or in parallel and if sequentially, then which platform to start with (again assuming resource allocation is not an issue).
As for me, developing both versions at the same time always means more time. You can have your design, workflow, architecture perfectly defined, but there'll always be changes during the development (not to say if there's an external client making decisions). If you're developing for both platforms in parallel, chances are that you will implement those changes twice, while if you first finish your app in one platform, you shouldn't find more unexpected surprises in the second one.
The next question then would be: which platform should I start from? I choose Android for two main reasons:
It's a lot easier to refactor code / project structure (at least for me) in eclipse than xcode.
I design the user interface keeping in mind the largest resolution (Android xxhdpi), then I cut my final png assets once using android resources naming conventions (which is more restrictive than ios), and run automated tasks for the rest of densities (xhdpi, hdpi, mdpi, iOS and iOS#2x)
Regarding cross-platform frameworks (i.e. phonegap), imho the effort will never be divided by two, and the user experience will never be close to the experience reached with a native application. Unless your app is extremely simple, I'd highly discourage these kind of frameworks.
We had the very same debate when we started developing the app we're working on.
First, I should say that if your app is simple enough (doesn't have too many heavy animations, 3D, etc), you might want to look at some multi-platform solutions:
http://mobiledevices.about.com/od/mobileappbasics/tp/Top-5-Tools-Multi-Platform-Mobile-App-Development.htm
I personally feel that multi-platform solutions are still too far behind native apps, but it might be suitable for some apps.
In the end, we decided to develop the infrastructure of our app on one platform (Android), and then start building the app on the other platform (iOS), once the strength and performance of the Android app's infrastructure was proven. When we developed the iOS app, the infrastructure from the Android app was copied.
There are several advantages to this:
After you finish designing the architecture of the app, you test it once on one platform. If the architecture failed to hold up, you don't need to start 2 projects from scratch - only one.
Once you develop the app once, at least the infrastructure, you've already gone through all the major hurdles of development. This will allow you to complete the development of the other platform with relative ease and speed.
Developing 2 projects simultaneously will probably result in significant differences in the way the code works in both platforms. While there will always be some differences, due to the large differences between the platforms, it's better to minimize the difference between the way the apps operate - this will make maintaining the apps in the future much easier. (Solutions to problems will be essentially the same - iOS & Android teams can copy their solutions off each other).
Developing simultaneously will probably be quicker, but riskier, and will cost more time when you need to maintain your app.
Hope this helps your decision making :)
That depends strongly how you develop the app. If you develop on multi-plattform, I would suggest to us a framework like phonegap: http://phonegap.com/ . With this approach your question disappears and you saved half of the effort.
If all resources are available and requirements are clear then you should go for parallel development because its not best practice to make any resource sit idle.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
THIS QUESTION HAS MOVED TO https://softwarerecs.stackexchange.com/questions/27841/plugins-architecture-for-an-android-app
I want to implement a plugin system for an Open Source app, because it has become really large, with many features that only a few users need. Releasing different apps is not a good solution, because userA wants feature7 and feature24 whilst userB wants feature39 and feature24.
Where can I find a good example of a plugin architecture?
Here is what I would like a plugin to be able to do:
Redefine the layout of a particular screen (load deflated XML?)
Redefine a method of a class (load dex class?, AOP?)
For instance, one of the plugins must add a button on a particular screen, and clicking this button increments a value in the app's database. This is not doable with Content Providers and Intents, as far as I know.
I want to avoid making the core app's code complex with tons of hooks everywhere.
The form of the plugin could be a file on the SD card, an app, or anything else.
I have done a framework that works like Robo-guice with some of its primary IoC functions. (Cut down on boilerplate codes that load views/service etc...)
But the core of which, I believe is the solution to your problem, is the ability to load separate APK "plugin" files, that includes "res" as well as <layouts>.xml files. The <layouts>.xml file can be independently inflated by the classes within that APK. That is, you can load a CustomView (that inflates its own <layout>.xml) into an originating/parent App. All this is done without the Parent App APK knowing how the UI was inflated in the plugin APK.
Example of what I mean:
I have a Mapping App, the framework will dynamically scan installed APK that matches the "contract" for a "add-on function" plugin, and loads the UI specific to it onto the App's View as a floating panel.
I would say a plugin framework for Android is do-able, as Android has most if not all of the necessary built in APIs to accomplish this.
These are your friends in this area of plugin development for Android:
PackageManager (Scan install packages, aka Plugins)
DexClassLoader (ClassNotFoundException will be a pain if you don't use the correct ClassLoader btw)
Java Reflection
Where can I find a good example of a plugin architecture?
Roman Nurik from Google has implemented a nice plugins framework in his open source app dash clock. The plugins themselves are Services that extend the DashClockExtension class in the API and are installed as completely independent APK files with their own resources. It's quite a lot of work defining the communication protocol via the AIDL, but it's nice and clean and works very well.
one of the plugins must add a button on a particular screen, and clicking this button increments a value in the app's database.
The parts of the main Layout which can be modified by the plugin will need to be pre-defined by the core app, and exposed via the communication protocol. It should be possible for the plugin to inflate an arbitrary layout, and send it to the main app, which could put that inside a pre-allocated area of it's own Layout.
If you are just going for an increase in modularity, I would recommend using a dependency injection container such as PicoContainer, Guice or Spring.
If you want a light-weight plug-in architecture, then go for Java Plugin Framework (JPF).
It allows you to define extension points, which can be implemented by your modules. The primary job of the plug-in framework is to provide a way that you can bundle these modules (as jars), which are dynamically found by the core application and given as implementations of the extension point.