Ok, so from reading previous posts and the guides, I get it-- Ionic is for building hybrid mobile apps with Cordova/Phonegap, not responsive websites.
But…
Given that the desktop web app I’ll be building is almost surely based on AngularJS, it seems a tad silly to maintain two completely seperate code bases with a lot of identical code.
Also, part of my motivation for wanting to do a hybrid app in the first place is to rapidly deploy a mobile app + web app in an early stage start-up situation for the lowest cost possible by ideally writing just one set of code that runs everywhere. I assume many people drawn towards Ionic have similar motivations.
What have others done to reduce code duplication when deploying a web app and a hybrid Ionic app at the same time?
i really liked your question, because i too have the same question. @mhartington I liked your video, but you didn’t answered our question.
I mean, I want to know what’s the best practice to share code with Ionic, not in general. Ionic has a very specific workflow.
So, has anyone achieved the goal of sharing code between Ionic app and desktop app?
So for now, its best write new views for desktop, but since it’s angular, you can reuse 90% of your code.
While ionic does have a really specific workflow, it’s all based on gulp, so it’s really easy to customize. You could setup a build process to have three folders. Shared, mobile, and desktop.
It may take a bit to configure, but it is possible.
I like that structure, it feels just like Microsoft’s Universal Apps - and it makes sense!
But how you envision this? Maybe the gulp task could copy everything below ./shared to ./desktop/dev and ./mobile/dev and then copy mobile/desktop specific resources? What do you think?
Changes to the build process are pretty straightforward. What is a harder, however, is how to manage css and javascript code that is shared between the two builds.
Here are some opportunities for code sharing:
Server Code. As long as you create a general purpose api it should be possible to access the same server code from either environment.
Models. Use the same model to support both environments.
Controllers. Use the same controllers to support both environments. There may be cases where methods are only used in one of the environments, but it should still be possible o use the same controllers. Note that this will mean keeping html formatting out of the controllers.
Directives. Create two different templates for each directive so that the directive can branch based on the environment and use the appropriate template. For example, you might use an for ionic and some other
classes for web.
Navigation Bar. The top level navigation will likely be very different in the two environments. You will need to add some code so that your views can configure their container appropriately.
Icons. You can use ionicons (or other icon fonts) on both environments as long as you include the appropriate css and fonts. This will require you to use a subset of the ionic css file since using the full css file will conflict with other frameworks.
Controls. There are lots of ui controls that will need to be different. Menus, choice lists, pickers, modals, etc. In some cases a control will only exist in one environment and you will need to figure out how to handle it in the other environment.
Styles. This ends up being surprisingly difficult. A common case is to try to use a different framework for the web app (e.g. bootstrap). If you want a common color palette or other base styles you will need to customize the scss files for one (or both) frameworks using scss variables. Ideally you would have the same css class names with roughly the same behavior but this is often not the case. Class names can also connect with directives (e.g. ion-item) so it can be hard to figure out how to match them up.
Another wrinkle is that supporting iPad sized screens often ends up as a hybrid of the two approaches. The standard style does not work that well on large screens.
Also keep in mind that if you are building for a web application target, it may still end up running on a phone. If you want the user to be able to to use Safari on an iPhone and have it look like an iPhone app you may end up wanting to use your ionic build to provide the phone ui.
The reality is that it takes quite a bit of work to provide good support for both environments. It is much easier than using native iOS, however.
It would be great if ionic could provide the same platform support as bootstrap (even if some features were not available on all browsers) and could allow the framework to co-exist with bootstrap. This would also have benefits of letting you use third party controls within ionic.
I don’t think we need to go that far.
For me, all html/css should be different. It makes no sense to reuse the index.html with script references, for example. So, scripts and styles won’t be a problem, since they should be declared in different html’s anyway.
My goal is to share controllers, models, services, constants and configs. The backend api will be the same (that’s the point). What you guys think?
yeah… but this also begs the question about bower components. should an app like this mix bower components? that’s a problem. I’m seeing that sharing this code is not that simple. It’s not a simple copy/past of files
After some thought, I think both apps can share the same bower.json, the real deal is with the gulp file, that needs to be extremely customized to handle different components
We’re doing this at my startup, we use multiple Git repos to achieve what we need. We put all of our shared angular directives/controllers/services/etc. in a shared Git repository, then reference it using Bower from both our Web and Mobile projects. It’s working like a charm!
And did you tried to use a git submodule? I am trying to combine angular-fullstack generator with generator-m-ionic, does anybody has experiences with this approach?
So then you commit something in web and easily merge it to mobile.
heres a video which could help