From the time Windows Store Apps has been launched and highly promoted by Microsoft as a new model and future technology to go on for Windows desktop applications,the much anticipated buzz failed as the terms to use Windows Store Apps came into picture. One of the most highly touch-centric technology beating WPF for high graphic UI development, Store Apps did capture an eye of the developers.
Many WPF enthusiasts seems to be learning Store Apps development and praising as a new development technology for desktop. Having said that, Surface tab' failure in the consumer market and developers around the world facing stumbling blocks while developing Store Apps, especially while deployment, is making everybody nervous about the future of Store Apps.
But for now, lets just list some of the problems that a traditional Windows desktop developer would find discomforting, would even try and genuinely quote reasons why Microsoft would has come up with such a technology, by not just criticizing, but by understanding their perspective.
Restricted use of database
Use of database is completely restricted besides the local in process SQLite, which is a complete NO from the perspective of Enterprise application. No LOBs for sure. Now lets just think for a second why Microsoft didn't bother to give this access. Well to me it clearly shouts AZURE. Lets be real now, we all know that the future is Cloud development and for Windows cloud is Azure. So did Store Apps restrict from Azure ? - NO. Use of Azure with Store Apps I think answers to all the database access problems.
Restricted use of file writing to the OS
Yes, we cannot write to C:\temp from Store Apps. But when writing files on OS from Enterprise Applications, we understand very well that there are many other applications that will also be saving their data on the same location and making it unmanageable. Traditional desktop development provided these features, but now are the days coming of Cloud, where user does not want their data to be saving on personal hard disks for safety of course. Saving files on Cloud is much better than saving files locally. Yet file writing is still possible to safe locations through Store Apps. So user specific application data can be saved on disk. Cloud developers understand this and do not feel bothered about the restrictions regarding the file writing as they do not require them any more. Cloud based application developers will rarely require file writing and themselves won't write on locations like TEMP.
No deployment of Store Apps from Company's Server directly
Store Apps are deployed directly from Windows Store which probably is not an answer to the Enterprise application deployment. This seems to be a big change in the deployment methodologies and as promised Microsoft will surely provide an answer to this soon. But looking at the capabilities and abilities of Store Apps to communicate with each other, very soon we may not think of this as a problem. The communication abilities of Store Apps with each other gives us a clear idea that Microsoft is suggesting us to split the Enterprise applications into multiple smaller apps based on modules and allowing them to communicating with each other. So while developing itself we can develop and upload multiple apps and can deploy them individually with ease through Store Apps. This is also a cost reducing approach, if Windows Store itself allows us to deploy these apps. No added cost of maintenance of company' servers for deployment purposes. Clearly this is a thing of future but without clinging on to the past.
What must be kept in mind while migrating an Enterprise Application to Store Apps ?
A shift in mentality is required to design using the new Store Apps - Split the huge application with clear user interactivity into separate modules and then develop them into various small and modular apps.
Furthermore, another switch required from traditional database to Azure. This is what will allow us a great ability to manage huge amount of data efficiently.
Also do not forget to use the Tiles and Notifications which provides a way to provide information to the user even when the app is not running.
Charms and contracts are the ones which allows Store Apps to communicate amongst themselves, which I think will need to explore while developing smaller sets of apps from a large Enterprise Application.
XAML is same across Store Apps and WPF, so not all of the things change..
Although, there Microsoft wants to keep a market place holding with store apps but they are widely used advertising purposes, which should not really bother the Enterprise development.
Windows Store Apps is in a very initial stage right now. But well if today' winner is undoubtedly WPF, with the future of the desktop development going towards Cloud, WPF does seem a lot more backward, when it comes to gadgets and abilities like sensors. The ease of great UI development through WPF has made very much clear for Store Apps to take the same ahead, which it does in a very smart way. Many traditional developers coming from Windows Forms development and now using WPF might not want to shift to Store Apps because it does not allow the traditional privileges. But the technology is taken very well by the modern WPF developers, which very well explains the difference between traditional and modern people ;)
Many WPF enthusiasts seems to be learning Store Apps development and praising as a new development technology for desktop. Having said that, Surface tab' failure in the consumer market and developers around the world facing stumbling blocks while developing Store Apps, especially while deployment, is making everybody nervous about the future of Store Apps.
But for now, lets just list some of the problems that a traditional Windows desktop developer would find discomforting, would even try and genuinely quote reasons why Microsoft would has come up with such a technology, by not just criticizing, but by understanding their perspective.
Restricted use of database
Use of database is completely restricted besides the local in process SQLite, which is a complete NO from the perspective of Enterprise application. No LOBs for sure. Now lets just think for a second why Microsoft didn't bother to give this access. Well to me it clearly shouts AZURE. Lets be real now, we all know that the future is Cloud development and for Windows cloud is Azure. So did Store Apps restrict from Azure ? - NO. Use of Azure with Store Apps I think answers to all the database access problems.
Restricted use of file writing to the OS
Yes, we cannot write to C:\temp from Store Apps. But when writing files on OS from Enterprise Applications, we understand very well that there are many other applications that will also be saving their data on the same location and making it unmanageable. Traditional desktop development provided these features, but now are the days coming of Cloud, where user does not want their data to be saving on personal hard disks for safety of course. Saving files on Cloud is much better than saving files locally. Yet file writing is still possible to safe locations through Store Apps. So user specific application data can be saved on disk. Cloud developers understand this and do not feel bothered about the restrictions regarding the file writing as they do not require them any more. Cloud based application developers will rarely require file writing and themselves won't write on locations like TEMP.
No deployment of Store Apps from Company's Server directly
Store Apps are deployed directly from Windows Store which probably is not an answer to the Enterprise application deployment. This seems to be a big change in the deployment methodologies and as promised Microsoft will surely provide an answer to this soon. But looking at the capabilities and abilities of Store Apps to communicate with each other, very soon we may not think of this as a problem. The communication abilities of Store Apps with each other gives us a clear idea that Microsoft is suggesting us to split the Enterprise applications into multiple smaller apps based on modules and allowing them to communicating with each other. So while developing itself we can develop and upload multiple apps and can deploy them individually with ease through Store Apps. This is also a cost reducing approach, if Windows Store itself allows us to deploy these apps. No added cost of maintenance of company' servers for deployment purposes. Clearly this is a thing of future but without clinging on to the past.
What must be kept in mind while migrating an Enterprise Application to Store Apps ?
A shift in mentality is required to design using the new Store Apps - Split the huge application with clear user interactivity into separate modules and then develop them into various small and modular apps.
Furthermore, another switch required from traditional database to Azure. This is what will allow us a great ability to manage huge amount of data efficiently.
Also do not forget to use the Tiles and Notifications which provides a way to provide information to the user even when the app is not running.
Charms and contracts are the ones which allows Store Apps to communicate amongst themselves, which I think will need to explore while developing smaller sets of apps from a large Enterprise Application.
XAML is same across Store Apps and WPF, so not all of the things change..
Although, there Microsoft wants to keep a market place holding with store apps but they are widely used advertising purposes, which should not really bother the Enterprise development.
Windows Store Apps is in a very initial stage right now. But well if today' winner is undoubtedly WPF, with the future of the desktop development going towards Cloud, WPF does seem a lot more backward, when it comes to gadgets and abilities like sensors. The ease of great UI development through WPF has made very much clear for Store Apps to take the same ahead, which it does in a very smart way. Many traditional developers coming from Windows Forms development and now using WPF might not want to shift to Store Apps because it does not allow the traditional privileges. But the technology is taken very well by the modern WPF developers, which very well explains the difference between traditional and modern people ;)
