Before i start exploring the deep ends of tvOS, I'd rather turn to the community and get expert advice...
I am planning to write afwo-headed app :
First leg would run from FileMaker Go SDK given the simplicity to f development and straightforward database management.
Second leg would need to be an Apple tv component which only needs to display formatted text on screen, which is sent from the mobile bit described earlier.
Based on technologies i know so far my idea is to use FileMaker go ability to make http get/post requests to a RESTful service. Hence the question: is there anyway to run any such REST service from tvOS which will eventually display formatted text on screen based on requests pushed by mobile app ?
Does that even make any sense or, is there any more 'native' ways to achieve such stuff ?
Thanks
Cool project. Have a look at https://developer.apple.com/reference/tvmljs or search for TVML and TVJS.
Have you tried atvjs framework for building TVML apps? It lets you build and quickly prototype apps without much noise, abstracting the underlying hassles and complexities of a conventional TVML app.
I tried using PhoneJS - it's pretty easy to get started, and seems to provide a good framework. However, I usual prefer to avoid pre-built framework as they limit my flexibly. My main 2 concerns are:
PhoneJs uses Jquery, while a lot of people recomend using Zepto for better performance
Can I use native trigger.io/phonegap plugins?
As a rule of thumb, one should avoid using 'large' frameworks for mobile apps (for performance reasons) - that's why some people are against Jquery Mobile. PhoneJS is fairly large. Does anybody have any experience with PhoneJS performance?
Frameworks reduce flexibility - how easy is PhoneJS to customize/extend?
1. PhoneJs uses Jquery, while a lot of people recomend using Zepto for better performance
If you're set on using Zepto, despite the fact that certain benchmarks indicate that it doesn't perform any better than jQuery overall, it's likely that you'll be able to sub it in for jQuery without any great difficulty. Zepto is a jQuery clone with the code which handles edge cases for older browsers removed. Since you're developing for mobile I suspect this won't be an issue. The Foundation 4 framework, just as an example, allows you to choose between the two.
2. Can I use native trigger.io/phonegap plugins?
There's no reason why you couldn't use PhoneJS to structure your code and PhoneGap OR Trigger.io to build, package and deploy it. PhoneJS and PhoneGap / Trigger.io are frameworks which aim to solve completely different (but complementary) problems. In fact, the PhoneJS page specifically mentions packaging applications using PhoneGap. You would certainly be able to take full advantage of the APIs and plug-ins offered by whichever of the two (PhoneGap or Trigger.io) you decide to use with PhoneJS.
3. As a rule of thumb, one should avoid using 'large' frameworks for mobile apps (for performance reasons) - that's why some people are against Jquery Mobile. PhoneJS is fairly large. Does anybody have any experience with PhoneJS performance?
Aside from the effect on download times, which won't be an issue if you're using trigger.io / PhoneGap to package your code as a native application, there isn't necessarily a correlation between the size of a framework and the quality of the performance. From what I understand, the main problem with jQuery mobile is the amount of mark up it generates to render its UI components (link). That said, I used jQuery mobile recently on a mobile application packaged using PhoneGap and the performance was fine. In all likelihood I expect PhoneJS will be the same.
Note that any answer you get regarding performance of the framework from somebody who has used it is likely to be fairly subjective. If you're concerned, the best suggestion would be to download the framework, use it to prototype a representative subset of the functionality of your app, and test it on the lowest specced device you plan to target.
4. Frameworks reduce flexibility - how easy is PhoneJS to customize/extend?
A good framework may limit your flexibility somewhat but, I would argue, in a positive way. It will encourage you to structure your code so that it is consistent, de-coupled, and maintainable. Why waste your time reinventing the wheel when somebody has already done all the hard work for you?
Using a framework will save you from having to make a lot of boring decisions about file and code structure, and free your time so that you can concentrate on being creative and flexible in your solutions within the actual problem domain (ie. the stuff that is unique to your app).
PhoneJS consists of a suite of UI components and the Knockout MVVM framework, so it's roughly analogous to a combination of jQuery mobile and Backbone. If you don't like the UI components you could edit the code to improve them or choose not to use them at all. You'll get an idea of the flexibility of Knockout by looking at the documentation, but referring to my first point, if you find yourself fighting with it you're probably not getting the best out of it.
TLDR: The person best placed to assess whether the framework is a good fit for your requirements, in terms of performance and flexibility, is you. Download it, have a look at the code, play around with it, prototype some functionality yourself, and then make a decision based on your experience.
What is the better framework for development Windows Store application?
I have used http://metroprism.codeplex.com/ but now I want to use Caliburn.Micro or MVVM light for another project.
I have looked through several application examples for these frameworks but they were not complicated enough for me to estimate usage in bigger projects.
These two ones are completely documented but the problem I think is that documentation for winrt mixed with WP7, Silverlight and WPF and I doubt a bit in supporting all features and practices of using exactly for Windows Store application.
Could you give me advice what is the better one? Or what are the good practices in development for Winrt with modularity supporting like in Prism for WPF and Silverlight.
Thanks.
MVVM Light and Caliburn.Micro basically do the same thing but they do it using opposing "philosophies of development" in MVVM.
MVVM Light is a "view first" approach. In this approach the ViewModel is instantiated in by the View. In MVVM Light this is done via something called the ViewModelLocator, a static class that binds a public property directly to the DataContext of the View.
Caliburn.Micro is a "viewmodel first" approach. Here you find that the viewmodel and view are created by an IOC mechanism that binds the two together. You navigate from viewmodel to viewmodel, with the views being generated in response to the navigation to a ViewModel.
They both have different features:
MVVM Light has a really nice messaging system for allowing view models to communicate with each other in a loosely-coupled way.
MVVM Light has a really simple mechanism for injecting design-time data into your views. Basically it swaps out your runtime services with design-time services that feed data to your viewmodels and, in turn your view. This makes design time data really easy to use.
Caliburn.Micro has an amazing data-binding setup, where it handles most of your databinding scaffolding for you. Basically, it maps the names of methods and properties to the names of controls in the view and autowires them. This saves lots of code and is a really, really nice feature.
Caliburn.Micro uses a "Convention over Configuration" mechanism to map views to viewmodels. MainView maps to MainViewModel, etc. This means you've got no configuration, you just need to make sure that you've got your naming conventions sorted out.
I've used both frameworks (Caliburn.Micro for WP7 and MVVM Light for Windows 8 Store Apps) and like them both for different reasons. MVVM Light is easier to start using but Caliburn.Micro is probably more powerful. I've found them both more than adequate for writing moderately complex applications quickly.
Caliburn.Micro gives you clean XAML at the cost of some magic. MVVM Light is a clean and simple framework that is easy to understand and works well. Prism seems to be a bit heavier than MVVM Light and more business app oriented - it does more than just MVVM. There are many things to consider. Choosing what you already know will let you focus on adding features, but learning a new framework can certainly be a good learning experience helpful in future choices - so you could pick something you haven't used before if you want to learn. You could also write your own framework and only include what you need. I usually go somewhere between roll your own and MVVM Light because that is what I know, though if I were to build a bigger enterprise app - Prism might be better suited for the task. I haven't used Caliburn.Micro because the novelty of different MVVM approaches wore off for me and I just want to create apps. With WinRT a roll-your-own-framework approach is easier than with any platform before because the basic project templates already give you some foundations as I wrote in my Minimalistic MVVM blog post. I would recommend that approach if you already tried MVVM and want to use only the pieces you need - the framework will grow with your app. You can just grab pieces of code from other frameworks if you need them or write your own implementations of the patterns you need.
To summarize
If you want to learn - try something you haven't tried before or write your own framework
If you want to create an app quickly and it is not a huge app - use what you know or go minimalistic and don't use anything but what you get from the templates
If you are building a big app with lots of features - consider Prism or rather first think whether Windows Store is the right target platform for you since it seems to be focusing more on simple in and out tablet apps
i'm here to ask a general question about Extjs or any other web related technologies....
i found out that it is impossible to parse xml without the help of any webservice.....
so i would like to know about the pro's and cons about these kind of technologies specifically sencha.
whats the best feature you find intresting about this technology and also the worst thing...
ExtJS, SmartClient, YUI, MooTools, etc are all rich Internet application (RIA) frameworks that allow you to integrate at the JavaScript and/or Google Web Toolkit levels. I have generally seen ExtJS and SmartClient compared most frequently. I have used SmartClient myself and one reason I did was because of the licensing differences between the two.
The biggest advantage of something like ExtJS or SmartClient is that they allow you to focus on building a data-driven service that easily integrates with their rich set of widgets. This allows you to focus on your data and simply leverage their flexible, cross browser-ish, slick looking web GUI controls.
In my opinion, it's a great time saver and browser robustness advantage. You can combine these with things like JQuery, etc. In fact, you can use ExtJS and SmartClient together if you like. (although most people won't)
There's a data package in ExtJS & Sencha Touch that allows you to easily bind client apps to JSON, YQL, XML datasources.
You should probably take a look at the documentation for the data.* part of the ExtJS library: http://dev.sencha.com/deploy/dev/docs/?class=Ext.data.XmlStore and this area is further improving in the forthcoming EXT JS 4
We're building a web-based application that requires heavy image processing. We'd like this processing load to be on the client as much as possible and we'd like to support as much platforms (even mobiles) as much as possible.
Yeah, I know, wishful thinking
Here's the info:
Image processing is rasterization from some data. Think like creating a PNG image from a PDF file.
We don't have a lot of server power. So client-side processing is a bit of a must.
So, we're considering:
Flash - most widespread, but from what i read has lackluster development tools. (and no iPhone/iPad support for now).
Silverlight - allows us to use .NET CLR, so a big ++ (a lot of code is in .NET). But is not supported for most mobiles ( rumored android support in the future)
HTML5 + Javascript - probably the most "portable" option. The problem is having to rewrite all that image processing code in Javascript.
Any thoughts or architectures that might help?
Clarification: I don't need further ideas on what libraries are available for Silverlight and Javascript. My dilemma is
choosing Silverlight means no support for most mobiles
choosing Flash means we have to redevelop most of our code AND no iPhone/iPad support
HTML5 + Javascript we have to redevelop most of our code and not fully supported yet in all browsers
choosing two (Silverlight + Flash) will be too costly
Any out-of-the-box or bright ideas / alternatives I might be missing?
This is the sort of issue that software architects run up against all the time. As per usual, there is no ideal solution. You need to select which compromise is most acceptable to your business.
To summarise your problem, most of your image processing software is written in .NET. You'd like to run it client-side on mobile devices, but there is limited .NET penetration on mobiles. The alternatives with higher penetration (eg. Flash) would require you to re-write your code, which you can't afford to do. In addition, these alternatives are not supported on the iPhone/iPad.
What you ideally want is a way to run all your .NET code on most existing platforms, including iPhone/iPad. I can say with some confidence that no such solution currently exists - there is no "silver bullet" answer that you have overlooked.
So what will you need to compromise on? It seems to me that even if you redevelop in flash, you are still going to miss out on a major market (iPhone). And redeveloping software is extremely costly anyway.
Here is the best solution to your problem - you need to compromise on your "client side execution" constraint. If you execute server side, you get to keep your existing code, and also get to deploy to just about every mobile client, including the iPhone.
You said your server power is limited, but server processing power is cheap when compared to software development costs. Indeed, it is not all that expensive to outsource your server component and just pay for what you use. It's most likely that your application will only have low penetration to start off with. As the business grows, you will be able to afford to upgrade your server capacity.
I believe this is the best solution to your problem.
Host you image processing on Amazon E2C, Azure, or Google. IIRC E2C has many common image processing problems packaged and all ready to go.
Azure probably more familiar ground in term of sharing code as a web service
You just pay for CPU cycles and transfers/storage etc
I'm sure there will be Silverlight and JS people posting examples. Here are some image editors written in actionscript:
Phoenix
PhotoshopExpress
There is an ImageProcessing library to start with.
Plus PixelBender is available in Flash Player 10, it's fast, it runs in a separate thread
and people do some pretty mad things with it.
HTH
Some help for the Silverlight part:
There is an Silverlight image editor called Thumba.
And Nokola recently made one called EasyPainter and he will also provide the source code in the furure.
For the image conversion I would recommend the open source library ImageTools that also includes some basic effects.
Silverlight has a class for pixel manipulation of bitmaps called WriteableBitmap. The open source library WriteableBitmapEx is a collection of extension methods for Silverlight's WriteableBitmap. The WriteableBitmap API is very minimalistic and there's only the raw Pixels array for such operations. The WriteableBitmapEx library tries to compensate that with extensions methods that are easy to use like built in methods.
Pixel Shaders can also be used to make some fast and advanced effects. Although they are limited by Shader Model 2 shaders can be used for fast bluring, tinting and such things.
DISCLAIMER: I consider myself as an advocate of the Flash platform. I admire Silverlights huge potential as a technology to deploy almost any .NET content through the browser, but it has low penetration, is horribly marketed and -although perceived as such by many (mostly people who don't know either Flash or Silverlight)- is no competitor of Flash, as much as Flash is no competitor of Sliverlight. The idealist in me loves the idea of doing everything in HTML+JS using a standard, instead of relying on 3rd party proprietary software. But the truth is, JS is slow and the API is limited, and implementations of JS, HTML and CSS are terribly inconsistent accross browsers.
If you really wanna stick to .NET and are so interested in targeting the iPhone and its siblings, then you might wanna check out MonoTouch.
Still, even though this may surprise you, I am going to tell you to use Flash. :)
Why? The image processing bit is the smallest part of your application. Whatever it is you are writing, I am very sure of that. I don't know about Silverlight, but in Flash the filters used by "Thumba" and "EasyPainter" can be created within a day, most of them simply using ConvolutionFilter, ColorMatrixFilter, DisplacementMapFilter and BitmapData::paletteMap or even simply by applying one of the other filters Flash offers out of the box. Any additional things can be created using PixelBender, which was pointed out by George. The kernel language is a subset of C, so porting classic filters shouldn't be too time consuming. Also alchemy (an LLVM backend targeting Flash Player 10) would be an option worth investigating, although it's not very stable yet.
The biggest part of your app will be a lot of GUI design, GUI implementation, Business Logics etc. Flash is really great when it comes to simple, yet reasonably fast image manipulation and with the Flex framework and MXML you have a powerful tool to productively create the GUI of your app, that can interoperate very well with a multitude of server solutions for virtually any platform.
Also, Flash has a great and active community, offering tons of tutorials, code snippets, libraries and frameworks, and a big ecosystem, with cross-compilation tools to deliver flash content to other platforms (including the upcoming Flash CS5, or the mentioned Elips). I don't understand, where you got the impression, that the Flash platform lacks developement tools. The difference to the .NET suite is that they are provided by a multitude of vendors. The upcoming Flash Player 10.1 was already pointed out by George, but never the less, I wanted to stress, that this makes many of the cross-plattform considerations obsolete.
Last but not least, I'd like to point out Haxe. It allows compiling to SWF, but also to C++, using the very same API provided by NME, to target the iPhone. Also there's work in progress on an android backend. If you're aren't playing to launch within the next 4-5 months, then this is definitely an option.
Your issue is a perfect target for the Haxe programming language. Haxe is written for the web and can compile to JavaScript, Flash and Objective-C (possibly Java/.NET soon).
So you do not choose which platform you are going to invest in but in which language. Haxe is easily adoptable for an AcitonScript programmer.
It makes no sense to run your imageprocessing algorithms in a JavaScript sandbox when Flash is available because it will be much faster. It makes also no sense to run heavy image processing algorithms on a mobile device like the iPhone with JavaScript. I would only support JavaScript as the worst fallback solution.
If you do not like to use Haxe I would go with Flash. You can deploy your Flash application for the iPhone aswell if that is your problem. This is also very great because you get native ARM code. There are actually great tools for professional Flash development available. FDT and IntelliJ IDEA are two of them. The best Haxe IDE is probably FlashDevelop at the moment of writing.
So I would definitly not use JavaScript as the only solution. Haxe is perfect for what you try to achieve. If you do not trust or do not want to invest in Haxe you can use Flash because of the iPhone/iPad export.
Depending on your usecase I would also encourage you to look at cloud hosting like Amazon EC2 and Google AppEngine for instance. Hosting costs are cheap and scaling will be easy for your task. The experience will be much better when it comes to complex operations that can take even a lot of time on a desktop system.
In addition to other answers, another option may be a hybrid solution. For example, use Flash/Silverlight for the majority of your target audience and use server-side processing for those that don't support it (or you could create a native app for iP[hone|ad])
You may have to do something like this anyway as the mobiles you are targetting may have insufficient processing power depending how complex your image processing gets.
Of course you still have the option of upgrading your server which, although you've currently discounted, is probably far cheaper than spending development time creating/deploying/testing a client-side solution.
You can use Silverlight for all Silverlight enabled clients and for non Silverlight clients, do the image processing server side. Since the Silverlight code is C#, you can double compile it to make (mostly)the same code work as Silverlight and non-Silverlight (i.e. server). This gets you the best of both worlds.
You don't say what language "all that code" you'd have to rewrite is in. Might a semiautomated translation to Javascript be practical?
Perhaps you could start out server-side, as CraigS suggests, and then move functions into the client over time instead of rewriting all at once.
Have you checked the editor of Pixlr.com ?
Take a look at their API as well..
The best solution is to use silverlight (so you already have the code ready). If the client can't run it (mobile phones, etc) then process it server-side.
It's the best compromise.
Depends on the type of image processing and the end user experience you are targeting.
As you are looking to target mobile phones your image processing will need to take into consideration the type of handset the user or the receipient has (if messaging via SMS/MMS), as different handsets have different resolution screens and handle different image formats for main images and thumbnails.
I'd suggest that you consider a hybrid cloud architecture as was mentioned in the Microsoft PDC keynotes this year. This would enable you to have your own server(s) to support your application, but if you require additional capacity due you scale out into the cloud using AppFabric.
Additionally, to maximise the market availability of your product pulling the image processing to a common reusable infrastructure allows you to target different platforms, exploiting the positives in each.
I have worked on a solution that hosted its image processing and delivery infrastructure server side and then built different UI offerings allowing sales via desktops, MNOs and AppStores. It can work and from a business perspective can offer economies of scale benefits.
Why not mention Java Applet ?
Good sides are:
almost all browser support ?
need install JRE ?
all OS support
Java provide Java Advanced Image kits, but if c++ dll can be called, that is best (JNI can call c++ dll )
In Python, one of the most popular libraries for image processing is pillow. Through the pyodide project (python running inside browser via emscripten), it's possible to use libraries like pillow and numpy for image (or matrix) processing, and convert the output to a base64 string (via Python standard library). This can then be passed to your <img> html element, either native JS document or with a library like React.
The way I see it, there's no one solution that meets all of your needs. Your best option, imo, is to go with Flash and hope that Adobe sets an agreement with Apple to get Flash on the iPhone/iPad. The major downside, of course, is you'll have to rewrite much of your code.
If the mobile sector isn't absolutely critical, then choose the Silverlight option for reasons you mentioned already. You could also use Silverlight in an out-of-browser mode to work as a desktop application.