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
With the recent updates to Sencha Touch, it's looking more and more like a native app for iPhone and even iPad. There are still many differences and the documentation is a little lacking at the moment.
My question is, given that I am already fully capable of creating native app in Objective C, should I switch to Sencha Touch and PhoneGap, or start integrating those tools?
What are the pros and cons?
EDIT:
Thanks for the insightful points. One of my partners wrote up their opinion over the weekend with some ideas that haven't been mentioned here: Web vs Native: How Should You Write Your App?
Pros:
Easier to port to other platforms.
You can distribute outside the App Store if the app doesn't require any native APIs.
Cons:
Scrolling still doesn't feel quite right with any of the web-based touch frameworks.
Slower (hardware-accelerated CSS animations help, but it's not nearly as flexible as Core Animation).
Lacks full access to native hardware and OS-integration (PhoneGap provides some, but not everything), such as:
Push notifications.
Local notifications.
Background location updates (including significant location monitoring).
This is debatable, but in my opinion Cocoa Touch is easier to develop in than JavaScript + Sencha/XUI/etc.
Questions leading to your own answer:
Do you need the raw performance of a native ARM app? Or do you need an API that's only available to Objective C? (For instance, for real-time audio synthesis, etc.) Do you want to use Apple's latest APIs without waiting for some tool or library vendor?
Do you mind that your javascript source code in visible unencrypted inside every customer's .ipa file?
Or do you want to easily port a simpler app cross-platform?
Pros: None
Cons: It will never be as native as a
native app. And you depend on an API
that isn't yours, eg. all your apps
will be useless once they stop
maintaining their API.
However, if you were unexperienced and only needed to make a App for a short event (upcoming movie promotion, etc), this would be perfect as it would save you time. But well, if you want a App with a longer lifecycle, go native.
Forget the details of comparing these frameworks to native apps, native will always win. If your app needs to run on "multiple" platforms, then you are better off using PhoneGap and a javascript framework. These frameworks are going to take awhile to mature, so you'll have to figure out if you can get by on what they offer now. PhoneGap is also open source, so if there is something native that you want to expose, contribute to the project.
Related
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 1 year ago.
Improve this question
Hi I want to check out a new framework to develop an app. Now I'm wondering about which one to choose, for example React Native or Flutter. Can you give me some suggestions or experiences about what to choose and maybe their advantages or disadvantages?
Thanks!
Summary:
React uses JS, Flutter uses Dart
The learning curve for Flutter is pretty steep since if you don't already know Dart, you're going to have to learn that too as well as a new framework (and reactive programming).
For React Native, it's pretty easy to pick up if you have used React or just JS in general which I'm sure you have.
Architecture
Flutter tends to rely on the BLoC pattern which is endorsed by Google Developers.
React Native relies on Flux and Redux.
Ecosystem
Flutter came out in May 2017 so it has less of an ecosystem than React Native which came out two full years prior.
Compilation
Flutter compiles to device-native code which you can change when you create a Flutter project. All of this is done on one thread! For intensive works, you might want to use a Dart Isolate which spins up a new spot on the memory to do intensive works while Flutter works on the UI and other stuff. Dart is designed for asynchronous workloads. Dart has Streams and Futures (basically Promises in JS). You can use a package that essentially brings in Redux to Dart to allow for Observables (better Promises).
React Native does not compile to native-device code and instead compiles to device equivalent. The JS runs on a separate thread and communicates to UI components through bridges. For asynchronous workloads, you can use Promises like in JS.
Documentation
As far as documentation goes, React Native wins at being more user-friendly than Flutter. Although, Flutter does have what they call cookbooks with easy to follow along with code samples. Overall, this is up to you.
Cross Platform
Flutter allows you to make apps for way more devices than React Native can. React Native is only for Android & iOS (though you can make web apps with react-native-web, thanks #VilleKoo) while Flutter hopes to support desktop, and web apps as well as the aforementioned iOS & Android all from a single codebase which is pretty impressive. Keep in mind, web support is in beta and desktop apps are not stable at this moment in time.
Further reading:
https://nevercode.io/blog/flutter-vs-react-native-a-developers-perspective/
https://hackr.io/blog/react-native-vs-flutter
https://hackernoon.com/react-native-vs-flutter-which-is-preferred-for-you-bba108f808
I see that the technical side of the question is covered pretty well by the others, but it's worth having a look at this issue from the standpoint of the technology's popularity, community support, and how it will keep up in the long run. Here is what I've found:
The category of most loved technologies due to the StackOverflow statistics shows how many specialists began using a particular tool and would like to continue working with it. By this criterion, Flutter’s score is 68.17%, while React Native has 58.08% of voices. Github says that the number of open source projects is growing day by day. The statistics present the number of contributors to open-source projects. React Native has 9.1k contributors, while this number for Flutter reaches 13k. Google Trends is a metric that shows how often a particular query is entered into the search in relation to the overall search volume for a specific period. It means that it estimates a query as a percentage of all search queries in Google. We can see that Flutter’s popularity amounted to nearly twice the React Native. The average number of “Flutter” queries score is 86, while React Native takes 58. With Google Trends, we can also analyze how popular other hybrid frameworks are compared to the described two. The statistics have shown us that Flutter is the best hybrid app framework in 2020, and React Native is in second place. Interestingly, if we take the 5 years’ overview instead of 12 months, we can see the whole picture. The trend for Flutter has rapidly grown in the last 3 years’ time. The popularity of React Native and Cordova was stable, and Xamarin’s number of queries is steadily decreasing.
So as you see Flutter gains popularity very quickly, and I am rather surprised how quick it is. It looks like Flutter might be more future-proof because of the wider community, more new modules, and features, which result in better support, more updates, etc.
Here is some additional reading for you on that matter:
StackOverflow statistics 2021
Flutter vs React Native: Which is better?
Statistics about other frameworks' popularity
I've been using React Native for more than a year, but I never tried Expo deeply. I only made some test 3 months before. In that time I found that you were not allowed to write and integrate Java / Swift commponents if you needed to use them.
Also I found a bit difficult to reload the app depending on the wifi signal.
In some days, I will start a new middle size app. So I wonder if is it a good aproach to start it using Expo ?
Your question is mostly opinion based and it is likely to be closed. It would be best to ask if or how you can solve an enterprise issue with Expo.
To me, while Expo is promising and interesting, is only good for either small apps or prototypes.
Pretty much you answered the question yourself. Native intengration is not possiblr and sooner or later you are going to need it in your app, otherwise you will be very limited.
Also, it adds another layer of dependency into your project. Let's say Expo updates something that breaks your app, you might need to re write everything.
Big companies or big projects cannot be stopped by this. So, to me, Expo is not a very good approach for mid size apps and above, but of course, it depends on your objective.
Maybe this big app of yours is a one time app, that needs no native integration whatsover and that you don't mind if you need to re write in the future, then yes, you could use Expo since it could help you speed up delivery.
I'm about to make an application for ipad that has the following specifications:
download JSON (or xml) from server
download short audiofiles from server (locations are in the JSON from above)
save these to the iPad for offline use.
based on these files the user gets to do some exercises
user progress/results need to be saved to the device so they can continue where they left off the next time they launch the app.
My question: Can this be done with only html/css/jquery Phonegap? Or should I go native and make this all in Objective-C? Or can I combine phonegap and Objective-C?
Now I'd like to know how I can save a json file on the device for offline use.
Also I'd like to know how to download audio (or images or whatever) and save those to the device.
This can be done with PhoneGap/Cordova and its HTML5 approach.
If it is iPad only, then go native.
Your app's high level requirements do not sound too complicated. For more complex apps always consider that facebook just went native for iOS because of their performance issues. In the end, this may be the way to go for a number of apps. PhoneGap or other HTML5 or cross compiling approaches for 1000+ devices plus native solutions for the market leaders.
It depends on what level UX your are aiming for and how you think your app may expand in the future.
If you need full control over the user experience, then you will need to go native. All the physics involved in scrolling/swiping will be done for you. How much content will you have? if it's thousands of items then again native will offer the best performance. You can also perform certain tasks on background threads (my app did image compression and resizing before uploading the image, for example).
Otherwise - if you just want to get something out quick, go with phonegap.
*I speak as a developer who started out with Phonegap but went Native for performance reasons. Others may have had better experiences.
Comparing application build in native Objective-C with applications build with Webtool like PhoneGap, in terms of being fast, Objective-C apps always win, but in terms of building it fast with zero knowledge of Objective-C Web apps win.
If you have knowledge of Objective-C, in my opinion go with native Objective-C app, else do it with PhoneGap.
BTW, those functionality mentioned in your question can be done with both.
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
I am writing this very basic J2SE application which alerts the user with some info every now and then. Currently I am using the SystemTray and TrayIcon classes to show notifications, but I am not really pleased with that. It does not allow me to tweak the notifications, nor gives them a good look.
So, does anyone know an easy to use library to generate nice notifications?
btw, I will be porting to Linux (Ubuntu) to, but will be using notify-OSD there, which is exactly what I need.
Shameless plug: I've just released a project called Twinkle that is pretty much Growl for Java Swing.
I' not aware of a Java library abstracting all OS specific desktop notifications. But if you know, you are limited to Ubuntu (and perhaps a limited number of other OS), you can create a own Interface and implement it for the specific OS.
Ubuntu: You can access /usr/bin/notify-send via Runtime like this: usr/bin/notify-send -t 30000 "Text1" "Text2" -i /path/to/48x48.png
Mac OSX: Java Growl API
For JAVA implementations you may look at Jazz or Mylyn (see Java Desktop Notifications).
You can use JCommunique for cross-platform Java desktop notifications. Here is a short demo adapted from the examples on the wiki:
// makes a factory with the built-in clean theme
// themes are customizeable
NotificationFactory factory = new NotificationFactory(ThemePackagePresets.cleanLight());
// factories build notifications using a theme, while managers handle how
// how they appear on the screen
// this manager just simple pops up the notification in the specified location
// other managers do sliding, queues, etc.
NotificationManager plain = new SimpleManager(Location.NORTHEAST);
// creates a text notification; you can also have progress bar Notifications,
// icon Notifications, Notifications that ask for user feedback, etc.
TextNotification notification = factory.buildTextNotification("This is a title",
"This is a subtitle");
notification.setCloseOnClick(true);
// the notification will disappear after 2 seconds, or after you click it
plain.addNotification(notification, Time.seconds(2));
Brief confession: I also am the creator of this project. It's open source so I don't get any revenue from it.
Some other libraries to have a look at:
Twinkle
This is already mentioned in another answer so I won't say too much about it. I tried the Java Webstart demo and it looked pretty nice. It allows for some more complicated background color options such as gradients that JCommunique doesn't have.
About 3,500 lines.
Has a bunch of fancy styling options such as round vs. rectangle close buttons, gradient vs. solid color, and light vs. dark notifications. However, has just one sequential manager.
The wiki has links to javadocs and a getting started document.
No external dependencies (I think?).
JCarrierPigeon
Very lightweight. Looking at the jar, it has just six classes.
Depends on the "Timing Framework" library.
The website shows that it can do some sliding in effects, but I don't think it does fading or other types of animations.
JTelegraph
Requires JCarrierPigeon and "Timing Framework" in the classpath to build
Has dozens of nice-looking icons included with the project. I'm not sure how these are licensed, but they could be useful if you don't have your own.
As far as I can tell, it doesn't include many more features than those provided in JCarrierPigeon. It mainly includes a bunch of built in icons and a different API.
I can't post links to these since I don't have enough reputation, but they are easy to find on the internet.
Now I will try to objectively evaluate my own library in comparison with the above. Please keep in mind that this list is a bit more extensive since I know more about my project than the others. Let me know if there is anything that I'm missing.
JCommunique
Many features. As far as Notifications go, there are TextNotifications, IconNotifications, AcceptNotifications, and ProgressNotifications (show a progress bar). NotificationManagers handle how Notifications show. These include SimpleManager, QueueManager (scrolls down old Notifications to reveal new ones), SlideManager (slides Notifications into position), and SequenceManager (only shows a Notification when the previous one has disappeared).
Relatively large. I think it clocks in at about 2,500 lines in total.
Has a wiki with a number of examples.
Notifications look a bit plain because they can only be one solid color. Twinkle wins in this respect; it has gradients and outlines around its notifications.
A handful of built-in themes. At time of writing these include dark, light, and aqua. You can also add your own.
No external dependencies other than Java.
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
For Web Applications I use Ruby on Rails. And now it's time to see if I can code Desktop Applications with Ruby.
So I wonder which one I should choose.
The way I see it is MacRuby+IronRuby vs JRuby.
The former lets me have desktop applications for both Mac and Windows while the latter lets be have in both, but only learning one tool.
Is there strong arguments to use the former than the latter?
Will JRuby Desktop Applications be as native (or near-enough-native) as MacRuby+IronRuby Desktop Applications?
What are the pros and cons for each solution?
Im very new too Desktop development. Share your thoughts and experience!
MacRuby uses the native Apple Objective C stack.
Pros: Its class library is basically a wrapper for the Objective C GUI classes. You get fast native applications.
Cons: Only runs on Macs. They are not portable to the iPad or iPhone either (none of the Ruby solutions are).
IronRuby uses the native Windows .NET framework.
Pros: Use native WinForms to create rich native applications. It has access to the full .NET ecosystem of libraries.
Cons: Only runs on Windows.
JRuby uses the Java abstraction layer (JVM).
Pros: Multiple GUI libraries available. The most common ones are SWT and Swing. SWT uses native widgets and is faster and more native like. Swing is purely Java (emulated widgets) and is more portable. There are further libraries abstracting SWT and Swing to make them more Ruby friendly. Look at Profligacy for Swing for instance.
Cons: A layer above a layer above a layer. Swing and SWT are very mature but the Ruby layers above them are less so.
There is also another option
Ruby with the Qt library.
Qt is cross platform, uses native widgets and is written in C++. It is fairly fast but the library is complex and big.
My rule of thumb is the more complex your GUI is, the closer you should be to the native platform. You need to also evaluate the learning curve for each of these graphical libraries and the effort needed to port between platforms.
IronRuby just lots its main developer, so you may want to consider that one carefully. https://en.wikibooks.org/wiki/Ruby_Programming/GUI_Toolkit_Modules might help