I have been reading the abstracts on the website http://www.rikulo.org but all those cryptic vague statements do not help me. The examples are all about visuals.
I do not understand what this framework is capeable of doing. The big picture is missing.
What kind of apps can i build with rikulo?
Is there any access to the hardware?
Can is use the smartphones sensordata and send e.g. coordinates from my smartphone to a web service?
What are the limitations?
As described in this blog, Rikulo is aimed to provide a structured UI model for Web and mobile programming. We are the same team who developed ZK. With Rikulo, we'd like to take a step further since many things have been changed since we developed ZK in 2005. Also, both Dart and HTML 5 are young. It is an excellent moment to explore the best possible UI architecture for both Web and mobile programming.
For example, we use absolute positioning to give programmers 100% control the layout of UI rather than spending hours to figure out why it fails in certain combination. Another example is "recursive layered structure", such as layout manager and visual effect handling -- rather than ad hoc features targeting specific problems individually.
On the other hand, we don't have many widgets yet. It might be the reason that confused you. As a Apache licensed project, we hope we can have an active community for building widgets and addons, as long as we can really provide a solid and elegant architecture -- it is what we focus now and keep refining.
To access the hardware, you can use Rikulo Gap which is based on Cordova/PhoneGap. To communicate back the server, you can use Web socket or HttpRequest. We will have more advanced support for jsonizing, caching and communicating Dart objects between client and server, but it is not ready yet.
Technically, there is no limitation. Of course, the current number of widgets is definitely not enough, but it will get more in the near future. Furthermore, you always can create them with HTML 5 (and contribute back). However, for mobile applications, one thing you have to keep in mind: the performance won't be as good as the apps written in Objective C. The good is Rikulo is cross platform and your app can be accessed with Web browsers and as a native app.
Related
I am new to development and would like to develop an android application. I have previously built an application with Adobe Flash Builder 4.6 with Flex Mobile Project. I just recently noticed in 4.7 there is an option for Action Script Mobile Project.
Can someone please explain to me the difference between the two and the pros and cons to utilizing either or?
Pros:
Creating a Flex mobile project is easier (use Flex 4.6 with design mode to rapidly prototype, 4.7 to develop) and visually let's you drag and drop
You can use data binding and other convieniant built in tools
Like anything else, there's good and bad about using the Flex mobile project as oppose to a complete ActionScript based solution. Mainly, it's a lot easier to customize your preloadeder, your splash screen and other features similar to tht like customizing how your application handles screen. Below is a couple pros and cons of using the Flex mobile version instead of ActionScript.
Cons:
Slower performance
Can't use Adobe Scout, it's an awesome tool for real time benchmarking and profiling. Using the built in one is ok but it doesn't give you theamazing information that Scout provides.
My advice: if you're savvy enough to do everything in ActionScript, then definitely create an ActionScript project, your users will love you for it. Plus, it's not that much harder and it lets you have a myriad of additional control over your components. Also, you don't have to deal with the overhead that comes with data binding ( it generates event listeners, get and set methods and you can create much more efficient ones on your own). There are a number of other things that benefit you by creating an ActionScript version like refactoring and better subversion but those are more of incentives than anything else.
If you plan on making use of the declarative mark-up, built in UI components, and data binding which the Flex framework provides then you should probably start with a Flex Mobile Project. The downside to this approach is that the additional scaffolding of the Flex framework will incur a slight performance hit and will increase the over-all file size of your project.
On the other hand, if performance is critical and you don't need the declarative markup, built in UI components, or data binding provided by the Flex framework, then you should start with a pure ActionScript mobile project. Really simple applications, games, or applications with highly customised UIs would be examples of projects for which a pure ActionScript approach might be more suitable.
FYI, you can use Adobe Scout on Flex apps. Apache Flex now supports advanced Telemetry.
You can also add advanced telemetry to any SWF with the SWF Scout Enabler.
I am an iOS developer with decent experience, After a lot of decsion making, we have coome to a conclusion of using phoneGap for our next project which is suppose to be a multi platform app.
Now the question is what to use with PhoneGap, Sencha and jQuery Mobile?
I visited old posts at SO,Quora and a lot of blogs and came to a conclusion that, jQuery Mobile is good to start and learn but Sencha is much more powerful in terms of controls,MVC on client and extensibility.
I have used jquery,jquery plugins and ExtJS in the past and I am fine with either of their mobile counterparts .
So coming to the point, Our application will be designed by a designer who will not know what we will be using to make the app.
he will give us wireframes of the application and slices for images to put on buttons,tab bars etc.
This is how our standard iOS design process works.
So which of the two frameworks will suit this kind of development style where I will be able to replicate the UI given by the designer.
Coming from iOS, Sencha Touch might be a little closer to what you're used to. Having had a little iOS experience, I feel like ST has a much closer layout system. jQuery Mobile would be best if the implementor is used to building things for the browser.
I think both are equally customizable. Having that said ST provides more built in components and hooks whereas jqm wants you to do more on your own. Both frameworks differ extremely in their approach. Jqm uses a declarative designer friendly approach whereas ST uses an OOP programmer friendly approach.
I had selected sproutcore as a framework right before Ember forked from sproutcore. I am left uncertain of which way to go and a bit frustrated in the apparent dilution of efforts caused by the fragmentation - as rarely does that lead to better things. The efforts of Sproutcore 2.0 (now Ember) seemed to be going in the right direction of modularization and reuse of other javasript components (jQuery), however it is really unclear from an outside view why the two efforts had to split... couldn't we have modular code, and a widget library module too?
The main questions are:
What are the effective differences between the two efforts?
What is history of the split?
What is sproutcore future, where is it going now?
Is Ember going develop to be a complete replacement for sproutcore?
As someone who has both a Sproutcore app and an Ember app close to a production launch, I'll take a stab at your questions (re-ordered for clarity). All of the below is what I've observed with no inside knowledge. A bit of it is speculation, so I've enabled wiki mode on this answer, so that more informed people can correct details.
What is history of the split?
Here is what I've pieced together:
SproutCore was created by Charles Jolley's company Sproutit as the basis of their Mailroom product in 2007. Jolley later joined Apple and Sproutcore was used to build the original web apps for Mobile Me. The mandate was to recreate the experience of Mac apps like Mail and iCal, and that effort continues on Sproutcore today with iCloud.
Jolley left Apple and formed a company called Strobe in San Francisco with a vision in part to leverage Sproutcore. The team at Strobe decided that Sproutcore didn't fit many Web 2.0 use cases well enough, and was too much of an all-or-nothing proposition for developers, so they initiated an effort toward Sproutcore 2. The goals of Sproutcore 2 were modularity, and a more HTML-aware approach that would be more accessible to web developers everywhere. Backbone's early traction was part of this analysis.
After struggling to move the Sproutcore codebase toward this vision, the Strobe team decided to start fresh with Sproutcore 2 (internal codename Amber). Charles wrote the core Run Loop and key-value observer code. Yehuda Katz and Tom Dale were the lead Strobe developers on the project. The vision at the time was that Strobe and the community would eventually port over most features and functionality from Sproutcore 1.x to Sproutcore 2.
Strobe business efforts were not yielding hoped-for results, and the company weighed its options, eventually deciding on a acquisition of Strobe talent by Facebook. Before this happened, a number of Strobe employees, including Katz and Dale, split off to form a new company called Tilde.
Tilde decided to continue to develop Sproutcore 2, but change the name (to Amber.js and then Ember.js) and goals of the project. They dropped long-term goals of backward compatibility with Sproutcore. They dropped support for any kind of view widget library and focused on the HTML/CSS use case with tight integration of data binding with the Handlebars templating language.
Since the dissolution of Strobe, stewardship of Sproutcore 1.x has passed from Jolley to Tyler Keating, and the community has re-focused on cleaning up Sproutcore 1.x, which was in an uncomfortable place for a while when the idea of Sproutcore 2 was looming.
What are the effective differences between the two efforts?
The similarities in the projects are that they feature very similar object models. They have similar property, observer and binding systems, too.
Sproutcore includes a library of view widgets like toolbars, list views, grid views, buttons, and theming system, and a focus on defining the view layer via Javascript and absolute positioning managed by the library. It is very powerful for creating desktop-style apps on the web.
Ember has a smaller footprint. It features tight integration with Handlebars. It is an alternative to Backbone for many projects. It aims to provide a standard application architecture for client-side apps and eliminate boilerplate code.
Those differences will likely lead to the frameworks diverging, although there has been some consideration of adopting the same core. In that scenario, Sproutcore would use Ember's "metal" library and perhaps other core libs).
What is Sproutcore's future, where is it going now?
This thread has minutes from the a recent contributor's meetup.
https://groups.google.com/group/sproutcore/browse_thread/thread/aacf00a6047a866e#
The short-term roadmap is to focus on solidifying the marketing materials, demos, and codebase. The team recently released the Sproutcore Showcase. There is general consensus about replacing abbot, the Ruby build tools for Sproutcore, with a Javascript(node.js)-based solution, which is now under active development. There is also a desire for fewer "large" merges of code from companies like Apple and more frequent releases. Sproutcore 1.8 was recently released.
Is Ember going develop to be a complete replacement for sproutcore?
Not likely. The Ember core team has been clear that they have no intention of personally developing those missing features. It is possible that community members may develop those as separate projects -- flame.js is the most ambitious attempt so far. Ember's design choices make it easier to integrate with projects like jQuery UI, so a full replacement may or may not be necessary.
1) The official line is Sproutcore is intended for RIAs and Ember.js is intended for "web-styled" applications. So when you look at iCloud think Sproutcore and when you look at Twitter think Ember.js.
From the technical standpoint, Ember.js is focused on more modularized code and so called "semantic-templates" for views. Sproutcore is more monolithic.
2) I'm not sure anyone really knows. If you look at the timeline, Charles Jolley left Apple to form a company called Strobe, which developed a full-stack platform for application development. Strobe hired Yehuda Katz and others, who began working on slimming down SC so it would run better on mobile devices. After about a year, Yehuda left to form the company Tilde, and a month after that Facebook bought Strobe in what is widely regarded as a talent acquisition.
So interpret that as you will.
3) This is an excellent question. Recently there was a meetup and several things were discussed. Key points discussed were:
SC is still alive and kicking
Improve documentation (we have been hearing that for a while).
Keep the good parts the code that was introduced post 1.4.5 in development of SC2 and get rid of or move to optional modules other stuff (like Templates)
new javascript-based build tools
completely new canvas based view layer, called Blossom.
Some sort of foundation/corporate backing for SC
There are probably others that I missed
4) Definitely not a replacement, although you can use any framework to build any app (it's all javascript, after all).
Vaadin and Apache Click seem to be equally good, which one should I choose for developing my web application. Or rather, what are the Pros and Cons of each framework.
I'm a committer of Apache Click but hopefully you will find my opinion objective.
I don't know Vaadin at all, just had a cursory look at their website and examples and mission statement.
Apache Click and Vaadin are meant for different problem spaces. Apache Click is targeted at traditional enterprise web applications while Vaadin targets the Rich Internet Application (RIA) space.
Apache Click is a traditional share nothing, stateless framework. Unlike traditional action based web frameworks Click provides a slightly higher level of abstraction by using Pages and Components. At the of the day Click isn't a revolution. Its just one of many approaches of doing web application development. In my opinion its a very good approach, both from a developer and maintainer point of view. (In enterprise environments the developer and maintainer are often not the same individual, so I differentiate between the two roles).
However developers sometimes have requirements that cannot be satisfied by traditional web applications, which is where RIA comes in. They provide a richer user experience (think desktop) but this does not come for free. RIA comes at a cost in terms of complexity, productivity and time-to-market. It makes sense though, if the requirements are for a richer experience, you need to do more in order to deliver that experience.
My advice here is: think carefully about your requirements. Don't simply assume that RIA is better, there is a price to pay, so make sure you get return for your investment.
Lastly, if your requirement is for RIA, then you should compare Vaadin with Flex. If your requirement is for a more traditional web application then compare Click with Struts, Stripes, Wicket, Tapestry etc.
Kind regards
Bob
I use both ;-)
Click is the best for classic web applications (pure html with no/ small/ handmade javascript).
It is very lightweight (small size and stateless), less verbose (you can do your html in html with velocity/freemarker power ;-).
A real php-killer.
Vaadin is the best for desktop like enterprise applications.
It is statefull, heavyweight, verbose, but amazing.
Grails, Play!, Spring MVC is a real step back after Click/Vaadin.
So my advice: use both!
For most of your pages you will use Click, for complicated tasks - Vaadin.
I've been using Click since 2006. I've built various web applications with it in the last 4 years. All apps (B2B) are still going strong and continue to be maintained/added to now. The best things about Click IMO include:
Very little magic and almost no plumbing. It's all just plain java (and jsp/velocity/freemarker take your pick; or alternatively use all 3 if you so choose; I have for some scenarios because it's so easy to).
It's super fast (It doesn't mean your app won't be slow, it just means Click will never be the reason why your app is slow)
It is so easy to integrate your favourite java lib eg. Ibatis SQLMAP, Spring, displaytag, DWR etc.etc.
You don't need to buy a book to understand/use it (although you may need books for all the other 3rd part libs you plan to use).
Most of my code written 4 years ago still works with the current release. That is just awesome.
Click fits in your head. The whole framework that is. It is so simple you don't have too many questions even as a beginner.
The guys that maintain Click are super responsive and very noob friendly.
It's simplicity helps my apps adapt to new/old tech. i.e I can easily do AJAXy stuff if I want or not.
The form features make handling html forms very easy/fast.
The table features make displaying data super easy/fast
Click's features help me write apps very quickly. Makes the need for scaffolding unnecessary imo.
If you want a light weight, fast, easy to understand framework which helps you build applications as fast as you or your team are personally able to, check out click, it will be worth your while.
Before making your choice you should evaluate all options by taking them out on a test drive.
I'm not familiar with Click, and someone should correct me if I'm wrong, but I understand Click basically a technique to link your server side code to web pages. The UI is page-based and you define the UI with components corresponding to HTML elements. Ajax is not (yet) supported, I gather.
Vaadin operates at a higher level of abstraction. With Vaadin you get to concentrate on your business logic, and build your UI naturally with views, layouts and other components (check out the Sampler). You don't need to care about RPC, page transitions, HTML or templates. Vaadin gives you a fully cross-browser compliant Ajax UI that looks and works great out of the box. It's very easy to get started, and the forum is very active (>700 messages last month compared to 96 on the Click mailing list).
Disclaimer: I'm a member of the Vaadin team and have not used Click.
I would choose, and I already did in a few projects Click (over all other frameworks).
The main selling point for me was that I was able to learn Click and be quite productive in one week-end (Vaadin - but other frameworks too took me much more).
The free and available documentation for Click is much better - you can compare the sites yourself (even if the Vaadin site looks cooler, the Click site is simply more useful - at least it was for me).
The live examples are much better - I always look at them as a snippet repository, and just copy what I need from there (since I'm a lazy programmer :) ) - there's a "Page Java" and "Page HTML" link for every example that shows the source code for every available example.
Regarding the message traffic, I don't think that should be a criteria, since having so good free online docs, and the framework being so much simpler, the users simply don't need to ask that much.
Disclaimer: I'm just a simple user that have used both frameworks.
Is Apache wicket an option as well ?
My experience is with jboss/ejb/jquery, but looking at technologies for starting a new project. I've done a quick bit of research myself abd Vaadin seems to be very well regarded.
Surely Apache Wicket is something you can not ignore if you are comparing UI frameworks. ( I am doing same.) I dropped Vaadin because of poor documentation ( maybe I am not a good Googler.)
Currently comparing Wicket, Click, and ZK.
Click and Wicket are ahead so far for the following reasons:
Generates pure HTML instead of rendering UI using JavaScript which happens in GWT, Vaadin, and ZK. You can use HTML5 features then.
Even with native HTML, server-side binding of UI forms is possible.
You don't need to worry about communication with the server. ZK also does this but with their own language ZUML.
I have found server-side memory footprint higher in ZK in the case of components like the ZK Grid. (Memory footprint for Click is not known to me yet.)
I need to deploy a Delphi app in an environment that needs centralized data and file storage system (for document imaging) but has multiple branch offices with relatively poor inter connectivity. I believe a 3 tier database application is the best way to go so I can provide a rich desktop experience with relatively light-weight data transfer needs. So far I have looked briefly at Delphi Datasnap, kbmMW and Remobjects SDK. It seems that kbmMW and Remobjects SDK use the least bandwidth. Does anyone have any experience in deploying any of these technologies in a challenging environments with a significant number of users (I need to support 700+)? Thanks!
Depends if you are tied to remote datasets. If you aren't dataset bound then SOAP would likely be a good choice. Or, what I've done is write my own protocol that is similar to SOAP in nature. This was done before SOAP was standard and I'm glad I did - this gives you the ability to control more of the flow of data. It's given that if you have poor connectivity then you will be spending time supporting it. It's very nice if it's your own code you are supporting versus having to wait on a vendor. (Although KBM and REM are known to be pretty good vendors.)
Personal note: 700 users in a document imaging application over poor connectivity sounds like a mess. Spend the money on upgrading connectivity as it'll be cheaper in the long run.
Both kbmMW and RO SDK offer binary format, which is more compact than SOAP format,specially you are working with documents.
RO sdk seems to offer more GUI tools to help you doing your services.
Also give a RealThinClient SDK a look, it's a lightweight remoting framework.
But what ever framework you go with, your design of work will make it fast or slow, I have some applications working on slow 128kb lines, and it's working perfect without any user complain, but I don't do a large transfer for files.
One thing to remember...its not the number of users, but the number of them using the resources at the same time that will be the issue. Attempt to develop your application "server stateless" if at all possible, this will allow greater flexibility in the long term if you find you have to add more servers to the pool to support your customer base. The hardest thing about n-tier is scaling beyond the first server...plan on that from the start. Each request should not know anything about a prior request...or at the very least the request should have a way of passing the context so the server can look it up in a session table or something.
Personally, I would recommend RemObjects. I have used it with good results.
I don't know if it's the very best / most efficient (glad you asked this question!), but I've had good results w/RemObjects SDK + DataAbstract. The latter made much of the plumbing details less involved, which was helpful. Still implementing, but so far so good.
If you really wanna go "low-bandwidth" use BSD Sockets API - that'll give you full control over what's being sent and there you can send as little information as you want. Of course then you'll have to implement all the tiers yourself, but hey - that's still an option :D