When do you think is best to to use a mobile App Maker (Ex: Appery.io) and when to code using a framework (Ex: Ionic)?
Of course, that coding with a framework doesn't tie you to any App Maker label... But, besides that, any other matter I should consider.
I need to start a simple project that querys a some REST API and have some doubts.
So I thought about posting here to open my head to someone who has walked this road before.
I don't mean this to be an open ended question on what is the best framework and comparing them all. I am just trying to establish is it really necessary to go down the heavier more complicated frameworks or can I get a mature long term solution using something like Appery?
Thanks!
When it comes to mobile apps, and as in your case, apps that load dynamic data from server, it is usually better to go for mobile app frameworks rather than, for online app builders. There can be multiple reasons for this :
App builders usually come with a lot of features, but they almost always fail for some Custom client requirements.
They usually tend to cater the need for static apps, when it comes to dynamic apps that have a lot of data manipulation stuff, you should prefer your own framework and logic to do so..
You can almost everytime modify / tweak a framework, You can't do so with an appbuilder.
You aren't sharing your code on cloud [Matters if you are working for some critical organization / client].
You have total control over your code / view. You can tweak it, twist it and almost guarantee total ownership. All you are bound to is the limitation your framework imposes.
You can mix and match frameworks, that doesn't applies for an appbuilder.
These are some of my quick thoughts, there can be [and are] many more reasons for switching towards a mobile framework..
AppMakers are generally there as tools for Rapid Prototyping. These days they market that you can make production apps using Appmakers but when you start using them you will notice that one or some other requirement you have cannot be implemented. In my experience, app development time seems to be less for AppMakers but it is generally more. On the other hand Mobile App Frameworks provide a lot of flexibility and code reusability too.
Related
I am leading a web application with a standard client-server-database architecture. My original plan was to have the client in react.js, the server in django+python, and the database in MySQL. Now, the programmer in charge of the client side is an expert in Unity 3D Engine, and he suggested to use this to implement the client. The advantges are:
Very easy to design;
Cross-platform - can be compiled to web, Android and iPhone.
One disadvantage is that the file size is larger, but for our application, it is not a substantial concern.
What worries me is that I do not know of any non-game web-applications that are written in Unity Engine, so there may be some disadvantages that I am not aware of.
Question: what are the disadvantages of using Unity 3D Engine to design the client side of a web application (versus e.g. react.js)?
I will mention some drawbacks I might think of compared to the web side of developing a web app. However I want to mention first that unity's versatility makes it suitable for any application you might think of and that the feature of compiling for the web is so huge. The times I am mentioning below are not big (it will depend on the app), but are to be considered if what is being built is a web app.
Unity webgl build size is said to be large, so the init load time of your web might take some seconds. Getting your hands dirty improving that might not be feasible as the build is provided by unity, so you would also lose that flexibility improving the load times. Also if you dont have the unity's pro version, your will have the "made with unity" splash screen on your web.
You can check that building an empty or very simple project to check these two things.
If you are not using the engines features regarding the game dev side, would not make much sense to use unity for me, meaning the physics, animations, collisions etc. It is expected a larger load time for graphic things or games, not for current webs though.
Another thing to consider. Seems that you can handle the settings of your build to work in mobile browsers, check the documentation. However the layout adaptation when you are using the app in a mobile browser might be much tougher as you renounce to manipulate easily the html and css directly yourself and renouncing to all the js and css ecosystem that might provide this work done for you. May be not renouncing, but it should take longer to integrate those in your unity builds if that is even possible.
Also, unity webgl builds take a while to be made, so for testing and so on, the compile + building + deploy time is a bit of a drawback compared to a web "live loading" + deploy which is a much faster workflow.
Got a problem, and I am pretty sure there is a solution for this.
Currently we have a Website that sells goods & integrates with a thirty party for shopping cart. The shopping cart integration is through standard web re-direct.
Product works well on desktop browser. Its not that bad on browsers on tablets. Not so great on phone browsers. The problem on mobile device is for obvious reasons, as the pages are optimized.
The standard approach we can do is go about optimizing for mobile browsers, and be happy. My team is flying with optimizing for mobile web, because they think apps will be very difficult to do.
If we choose to go the native app model, is developing a library or package for each platform the only way? I am thinking, no in current world with so much technology advancement. I am not a fan of browser view on device, not the smooth experience.
Are there other options available? I was looking at HTML5 hybrid applications, but can't put a finger to be sure that will work for what I am looking for.
Frameworks aside, often times you can use a stylesheet meant for mobile devices and hide everything that is not absolutely vital. You could also consider WML, but I think you could live without it IMAO.
Writing apps for the iOS will require an investment in Apple developer tools and training in Objective-C. Android will call for Java and Eclipse, to name a few things.
When it comes to "native apps", you will need to code for whatever platform you are depending on. The number of platforms you work with is entirely up to you, but yes, each new platform may require a different implementation.
Personally, I would add some specialized markup/styles to make as many browsers as possible happy. If you want to expand, try to see where your target audience really lies and reach out to them on any medium you can afford to build on. I would zone in on specialized applications if there are benefits really worth chasing down that road.
Hybrid applications is a good option, but probably the devil in a box.
The hybrid approach with HTML5 fits your developer, because they will still use HTML, CSS and JS (e.g. with PhoneGap), but on the other hand you will get an medium satisfying UI (what you said you are not a fan of).
Pure native applications is probably a bit too much of all good, if your web app runs fine in a browser.
A way could be to go with compiled hybrid and cross-platform compatible solutions like xamarin or appcelerator, especially appcelerator uses JS, which is an advantage for you. This could result in a native UI (implemented in JS) and shared business logic code. So there are two benefits for you; first, just use JS, second, shared business logic code -> less work.
Other alternative would be to go with responsive or adaptive websites, realized with the help of CSS.
If you are looking for developing a hybrid app (phonegap + angularJS + backend), I would like to recommend Monaca. I've just recently discover it. It is very cool since it has phonegap inside its framework and its own backend. Moreover, it also has a fast and lightweight UI framework called OnsenUI which is based on Topcoat and AngularJS.
Even it is a hybrid app but it will give users the native application feel since it also provides native components to use in your hybrid apps. What is impressive about it, you don't even need to build and install your app to your device every time during development. That's what I love the most about this.
I hope it helps since I think it is just like what you are asking for. I'm just a novice developer and I find it is very easy to use.
First I'd like to make it clear, I'm not looking for a "my tech is better than yours" type of post; this is a real case scenario and I have been faced with this decision. With this in mind, let me explain:
We have a WinForms application. It started in the early .NET 1.0 but the first shipping version was using .NET 1.1. There are layers (like BusinessLayer.dll, Datalayer.dll, Framework.DLL, etc.) but at some point during the "long" development cycle of this application, the "presentation" layer (Win Forms) got infected with some code, thus the "separation between the code and the presentation with code behind" is some sort of myth.
Bad practices or whatever, the truth is that the application is there and it works.
Years passed and we had .NET 2.0, we slowly migrated and it mostly worked, had to change a few calls here and there. Last version did the same thing, but for .NET 3.5sp1. We needed some sort of Webservices thing, and decided to use WCF instead. It works fine.
But despite all these .NET upgrades, most of the application's codebase is still the same old rock and roll from 5 years ago. We use Gentle.NET (old and unmaintained now) for our dataobjects (it was a blessing 5 years ago!).
Our presentation layer, the winforms, are "nice looking" since we employ 90% of completely gdi+ custom controls. (whenever possible without having to hack the WinAPi). The application is touch based (i.e.: it makes use of the Ink but it doesn't rely on that), but the buttons, labels, etc, everything is "designed" to be used with a tactile device. (TabletPC or Touchscreen). Of course some users use keyboard/mouse.
With all that in mind, and with all this web2.0 and Internet fuzz (plus Jeff's posts ;) ), we are considering the possibility of rewriting the application but using a web technology.
The idea is obviously bringing more availability for our customers (they can use the system whenever/wherever they want), and less maintenance (we can upgrade and it is an instant upgrade for 'em all), etc. You know, the usual Internet vs WinApp thingy.
The problem is that given that this is the healthcare industry, not all of our customers might be willing to "move" their databases to our server/s, which is acceptable, and would force us to install a webserver/database server in their own servers so they have their own copy. Not a big problem (except we would have to update those manually but that's not an issue, given that we've been updating win32 apps for 5 years now!).
Now, back to the main "question".
The team has little Asp.NET experience, we did program a lot in ASP 2.0 (in 1999/2000) but that was a spaghetti of HTML+VBScript+CSS, so I don't think it counts. After all that experience (the Internet bubble!) we went back to VB6 then C#.NET 1x and you know the rest of the story. We're a small team of C# developers for WinForms. We've acquired some Linq To SQL Experience in our last .NET 3.5 ride, and we liked it. We felt it very natural and very "if we would have had this five years ago…" like.
Given all this, rewriting the application is not a "simple task" (not even if we wanted to do it in the already known C#.NET), it would take time and planning, but we could correct dozens of mistakes and with 5 years of experience working with the application, we now can say that we have a better idea of how the customers would like to use the software and what limitations we created (by ourselves) when we designed the current app.
All that "knowledge" of the application and the way the business works, could be applied to produce a much better application in terms of design and code and usability. Remember in .NET 1.1 we didn't even have generics! ;) (you'll see lots of ArrayList's hanging around here).
As an additional note, we use Crystal Reports (and, as usual, we hate it). We don't think the ink control is a "must" either. The HTML/CSS could be shaped to look the way we want it, although we're aware that HTML is not WinForms (and hence some things cannot be reproduced).
Do you think that planning this in MVC (or WebForms) would be too crazy?
I like the MVC (ruby on rails like) idea (I've never programmed in ruby beyond the basics of the book), so no one in our team is an expert, but we can always learn and read. It mustn't be "rocket science", must it?
I know that this whole question might be a little bit subjective, but would you replace an aging Winforms application with a new ASP/MVC/XXX web application? Do you have experience or have tried (and had success or failed) ?
Any insight in helping use better decide what to do will be appreciated.
Thanks in advance!
UPDATE: Thanks to all who responded, we'll evaluate whether this is a good move or not, it sure is a hell of work, but I am afraid the the desktop app is getting older (using old net 1.1 hacks) and tho it has been more or less working without problems in Vista and W7, I'm afraid a future update may break it.
Also, lots of "more or less core" parts of the application are exposing some badly designed ideas and we had to hack here and there to accomplish certain tasks. Part inexperience, part lack of 100% knowledge of how the business worked (and Customers not sure what they wanted).
A new application (in any form) would allow us to create a better foundation while retaining all the user knowledge.
But, it's a L O T of work :) So we'll consider all these options here.
As some of you have mentioned, maybe a thinner client and some (ab)use of WCF here and there might be more appropriate.
Once again, thanks to all!
It would be best to ditch all your efforts of reusing the desktop application code when you recreate the web app. Following are the reasons:
Web apps especially asp.net use a different model. For starters note http is stateless. Each time the browser talks to server you have to explicitly send the current content of all the controls on the current page. You would not have used such a model in your Windows application.
To decrease load on the network you want to optimize the size of viewstate and how frequent you make http requests. Again your existing window app does not have any such provisions.
Updating view. You might have different event handlers, threads and what not in your windows application to update the GUI in different scenarios. All of that will need to be replaced. Javascript is a totally different animal.
Security. When using a browser your access to the local disk is highly limited whereas you will take the same for granted in windows application. If there is any code in the windows app that requires local resources, then that is going to be a trouble spot for you.
I would recommend the following:
Verify if your current application has any local disk access requirements (e.g. read/write to local file etc).
As you write the different http modules or handlers, you can try leveraging some of the backend/ business logic part of the existing windows application.
Give some thought to what part of your application can become a web service.
It sounds like the application needs a lot of refactoring to clean it up. If you want to move to a web model, and have maximum reuse you will really need to do that. Before you move to a web model I think you need to understand if it will be possible to replicate your user interface in that model. Is it your unique selling point from a customer perspective? You want decisions like this to be user driven rather than purely technical decisions.
It sounds like your application is the perfect candidate for a thick client application, rather than the lowest common denominator web model.
Some things to consider:
How will the web interface impact the Tablet interaction?
What new customers will having a web version bring you?
Will existing customers abandon your product?
Do you have access to consultants or outside resource with the right skills to mentor you in web technology? If you don't you can rely on StackOverflow or other web resources to help. You need some good mentoring and guidance on the ground with you.
What happens if you start this effort and it takes much longer than you expect? You know the app but don't sound like you know the web. Past experience shows that massive rewrites like this can end in disaster (it never sounds so difficult at the start)
Can you possibly write new features in a web-based version?
Could you move to ClickOnce deployment to make the application easier to deploy to customers. One of the benefits of the web is easier (zero) deployment. Can you get closer to that?
Would it be easier to migrate to WPF and create a browser application with that?
Silverlight or Flex might be better options for creating a rich experience, and may be more approachable for WinForms developers. Is this a possibility?
It seems like your app. is one of those that works best as a desktop app. Though you want your users to be able to access your app. using a browser.
I would suggest refactoring as much as possible so that the GUI gets cleaner and don't have "code".
When you've done this, start developing a asp.net mvc app but keep your desktop app. You should be able to use all layers except the UI layer, making it easier/faster/... Now that mvc exists, I'd say webforms is more about letting non-web devs do web. But you know web, sort of, and you want control so mvc is the way to go.
I've been developing with XHTML, CSS and Javascript for about 4 years now.
I love it a lot and hate it a little. I've looked into Flash and Silverlight a bit, but as a developer, I'm not too keen on them.
One reason is that they lock you into a vendor and generally, into using that vendor's tools. E.g. Adobe Flash or Microsoft Visual Studio, etc.
Also, Silverlight seems to mix content, layout/styling and behavior and into a single markup language, whereas I like the XHTML way of separating them out in code, but bringing them together in the user's web browser.
I also applaud the usability of the web, e.g. back button, hyperlinks, etc. which are set-in-stone standards that people are used to dealing with.
However, I'm seeing a lot of industry support for Silverlight and Flash. As far as .NET Developer jobs, I'm seeing less jobs for front-end/.NET developers and more jobs for Silverlight/.NET developers.
Will HTML developers still be employable in the future, or should I consider moving to a proprietary platform such as Silverlight?
While Flash/Silverlight skills may be worth developing, I think you will find that general web development skills will still be required for some years to come. Mobile apps in particular seem to place more emphasis on good, basic web design without dependence on plugins and or client-side code. Eventually, I would expect web standards to evolve to subsume the best (or at least most used) features of proprietary plugins. The web, at least, seems to be a place where people tend to favor solutions that maintain independence over lock-in to specific vendor technologies.
No, I think that idea will never fully catch on. The problem is really about the platform being developed on.
Look at how accessible the web is. Almost any machine can get on the web. My phone, my iPod, my laptop, my 11 year old PII machine, my gaming tower, all can access the same web.
The devices I have are not the limit to what can reach the web either. I think just about every gaming platform and cell phone can get on the web, as well as thin terminals running any OS imaginable. I'm sure there are others also.
The big thing looks like it's going to be the mobile market in the next few years. Some mobile devices can run flash, but it isn't used much because of the poor support & performance. The only way that the mobile web can work is by using pure standards based solutions, because that's really the only baseline that can be trusted to exist.
No matter what proprietary technologies come out, I can always rely on the fact that my XHTML pages will still render successfully on whatever device decides to access it. The same can't be said for flash or silverlight.
At the same time, I can also guarantee you that there will be a bigger market for flash and silverlight because the web is becoming more "media rich" in some niche markets (YouTube, Adobe Air, Hulu, Google Gears, etc. to name a few examples). There will absolutely be a market for it, but I wouldn't say it will defeat XHTML and web standards because the web is constantly being redefined.
No matter how much Flash or Silverlight try to take on, the technology will move so fast that the only baseline that I think will remain will be standards like XHTML and CSS.
Flash has been around for years and still hasn't taken over. I think that is one good example of how hard it is to replace XHTML.
Go for server-side development of any kind, but I wouldn't become a Silverlight or Flash specialist.
<CrystalBallMode>
To be honest I can't see it happening. Other than the reasons mentioned by tvanfosson and DanHerbert, the XHTML + CSS + JS stack just grew mature enough so that things like AJAX and jQuery make pretty much all the lightweight client side stuff easy with these tools (as opposed to things like streaming video, heavy computations or sockets etc.)
Common technological inertia will just guarantee that the existing things will stay around. People are much more likely to use something that has been around for a while and has been extended to meet the latest requirements than to use something totally new. Of course there are great paradigm shifts every now and then like the native to managed code transition but I don't see that happening with Flash or Silverlight.
</CrystalBallMode>
My hope is that what comes out of all of this is a new standardized web platform truly suited to building the web applications that people want to see with tools that developers really want to use. I see all of the effort going to trying to shoehorn these legacy web technologies into the "Web 2.0" model and I just wish that this effort could go towards making a truly revolutionary "Web v.Next".
Don't get me wrong, I really like what jQuery is doing to make Javascript client code easier, but it's still Javascript and my personal preference is to work with strongly typed languages with productive development tools.
In the meantime, I think tools like Silverlight and Flash have a lot to offer and help you do things more easily in some cases than in other web technologies, and there are some things you simply can't do any other way. But I don't think Silverlight or Flash or any other technology is the end game, just a step in the right direction.
Consider for a moment that you can manipulate a web page using Javascript, (X)HTML, and CSS with a great deal of overlap in functionality and yet ALL three technologies remain in prominent use today. The reason for this is because all three languages are different tools meant to solve different problems and no one of them can serve as an adequate replacement for the other.
Its the same thing with Flash / Silverlight vs these existing web technologies. In fact, I work in a dev shop that builds Flash based e-learning. One of our current products was originally built to use a purely Flash-based solution for navigation, etc. However, as the product has continued to evolve we have actually moved a lot of the functionality from the Flash-based e-learning module and into regular html pages.
In other words, I don't think that we'll be abandoning the current tools that web developers use any time soon. For the most part I see Flash / Silverlight as additional tools that will solve particular problems better than we were able to solve them previously.
Neither one is going to win out anytime soon. I expect which one is used will depend entirely on the purpose for many years to come.
The reason you're seeing so many job offerings for Silverlight of late is because it's a relatively new technology and just recently gained some momentum.
Though, I do expect Silverlight to make quick work of Flash.
I sure hope so. And yes, I think they will. There will be some development on legacy (XHTML/CSS/JS) apps for re-tuning purposes, but I think there will come a day when new apps are simply not created on those platforms.
Mobile phones are the issue right now. Flash isn't available on many of the major phone models. And their browsers are all over the map. Luckily there's Webkit (iPhone and G1).
If Silverlight makes it to a web platform then it will be a nice viable alternative to the hodgepodge of technologies that are currently in use. FYI, Microsfoft says Silverlight on Android is very possible. On the iPhone, hard to say, Apple is weird about such things.
AOL recently created a RIA version of it's email client in Silverlight. Looks nice and there's no Javascript errors to worry about. From a developer standpoint, that's huge.
Has anybody got any real world stories build mobile web sites with NetBiscuits?
Someone told me it was the next big thing in mobile development (http://www.netbiscuits.com/home) and it looks pretty good from their site. Just wondered if anybody (besides them) has actually used it.
From a few months time working with it, I can say that they're indeed one of the best (if not the best) out there. The support is also insanely quick and good.
Only thing making me stop using it is the price. Especially if you're a small company and want to use their POI feature.
However I have yet to find a good replacement. May end up rolling my own version...
Edit: Related question.
They have created an entire xml (bml) based markup language that emulates html that has a very steep learning curve. I would seriously reconsider using it.
I have seen it working nicely. It also supports ASP.NET controls SDK that can be used to write ASP.NET app from Visual Studio. Once this app is deployed on your premise, you can use live bridge agent to connect this app to a Live Bridge server that Net Biscuits hosts. Your app is called a backend app in this case. This is a very useful feature when you do want to have Forms capability in your app and also want it to be accessible on NetBiscuits platform.
Check http://kb.netbiscuits.com/tactile/edc/livebridge_help.html. BiscuitML is also easier to grasp.
Look out for performance issues though. Customers in Australia have had response time issues - probably due to the Cloud Platform being located in USA/UK.