Posts Tagged ‘C#’
This time as a part of cross platform development I’d like to make a short review of Mono project’s implementations/frameworks – MonoTouch and Monodroidthat allow creating applications using .NET framework and languages.
MonoTouch is a framework that allows developers create iPhone applications using the compilation of C# and reusing the existing .NET source code, libraries and skills.
The MonoTouch includes:
• Mono for the iPhone, iPad and iPod Touch
• C# and .NET compilers – on the iPhone you will need to compile the existing C# code and tools with the help of MonoTouch compiler to make sure that all the assemblies are referenced.
• .NET Bindings to Native APIs – MonoTouch compiler turns to compile the .NET libraries and base assemblies to create native iPhone applications.
• Mac oriPhoneSDK -includes the Xcode IDE, iPhone Simulator, and a suite of additional tools for developing applications for iPhone, iPad and iPod Touch.
• MonoDevelop Integrationhelps developers to integrate all features/toolsets from the integrating.NET platform to the target iPhoneenvironment from zero in no time
• Libraries that bind the native CocoaTouch APIs – toolsets that help to create native application interfaces for iPhone, iPad and iPod Touch
Mono for Android (MonoDroid)is a software development environment kit that allows to create the applications that run on Android phones and tablets.
Mono for Android consists of the core Mono runtime, the Mono for Android bindings to the native Android APIs, a Visual Studio 2010 plug-in to develop Android applications and an SDK that contains the tools to build, debug and deploy your applications. The Visual Studio 2010 plug-in allows developers to use Visual Studio 2010 to develop, debug and deploy their applications to an Android simulator, an Android device, or the Android Application Store.
Being the customer of Mono product you get one-year subscription to its product updates. The updates engaged the bug fixes and API changes. You could check the latest updates for Mono on the website called Xamarian Developer Center following this linkhttp://docs.xamarin.com/.
One of the latest upgrades released in May of 2012 by Xamarian Mono for Android is considered the research project called XobotOS.
XobotOS – the attempt to put C# code in the place of removed Java code in Android operating system. The idea is to write native code using C# instead of Java seems to extend the opportunities of Mono project. As the developers say the transition from Dalvik to Mono virtual machine performed good results like high-performance and low-battery consuming. Sharpen was chosen as the tool convertor for porting million lines of Java code to C#. It was upgraded for XobotOs and presented as its part release. The next goal of the company isto provide the direct access to the graphics library Skia for building applications.
What is the pricing?
Monotouch/MonoDroidare available in Professional Edition and Enterprise Editions: Monotouch/MonoDroid costs $399 for the entry level Professional edition and $999 and $2,499 for the Enterprise and Enterprise Priority version. A trial version is available which isn’t time limited but only allows deployment to an iPhone simulator.
The development of applications using cross platforms development approach seems to give the right idea for the developers how to manage with different environments and languages. Having reviewed the Mono project frameworks the advantages both of them may be summed up as follows:
- Applications written in C# for Android (MonoDroid) could be easily ported to iOS (MonoTouch);
-The source code written on C#, could be reused in MonoDroid and MonoTouch;
- The full support of C#: Language Integrated Query (LINQ), delegates, lambdas, events, garbage collection and many other features
- The support of Visual Studio and XCodefor bothMonoDroid and MonoTouch
- New challenges and updates guides
If you know something about programming with MonoTouch/ModoDroid and you have anything to add to my review, please, feel free to share your thoughts and experience on this point.
Before you read the article I would like to notice that it’s just a subjenctive opinion :-)
So, what is PHP4 and ASP.Net? ASP.NET – is not a continuation of ASP, but is conceptually a new Microsoft technology, created as part of ideology. NET. Key stakeholders of .NET are scalability, cross-language interaction and shaky concept of “safe programming”.
PHP is conversely an open and free technology. Of course, it would be wrong to decipher PHP as Personal Home Page today, but we still can hear echoes from the past to these days. PHP is a scripting language, created exclusively for dynamic HTML output. This does not mean that it is impossible to create a major project, this means that a large project for PHP is expensive and difficult.
Programming in PHP does not require an expensive programming environment. It would be enough a textbook to learn how to write more or less workable scripts. But it doesn’t work with ASP.NET. There is nothing to do without Visual Studio, MSDN and sometimes access to internet. Most part of time anovice developer spends on studying MSDN. By that time when he have learnt heaped model of classes and all the necessary functions, Microsoft probably will come up with something new. But if you could learn it…
Using ASP.NET with Visual Studio it looks like to work with Delphi. The main languages in which applications written in ASP.NET are Visual Basic.NET and C #, respectively, are the heirs Visual Basic и Java/C++.Theoretically, under ASP.NET, you can write programs in any language for which there is a corresponding compiler. However, in practice, to create ASP.NETapplications are mainly used Visual Basic.NET and C #. “Native” environment of ASP.NET is IIS, running Windows. And yes, IIS is not known as the most stable web server, and Windows – is not the most stable operating system.
ASP.NET does not suit for small projects, and even more – for a few triggered groups that do not require precise control. The causes are many – from the high cost of the platform and ending with the complexity of the model classes.NET. When you collide with .Net you could think who could understand and learn it all? But then you understand – nobody. The credo of .Net is not to go to own business, write your module, learn its functions, know your place – this principle works fine in the collective .
In the ideology of Microsoft a programmer is a small cog in a well-established mechanism, singles have never been considered. Thus large projects accrue for .Net.
Thus there are no places for PHP programmers in such projects. Why? Because they will require a lot of coordinators, who must be paid. Most part of coordination in .Net takes over itself. PHP technology is fundamentally different from ASP.NET. PHP resembles a mixture of C and Perl with a little spice of Basic and Pascal. But ASP.Net looks like a classic
PHP4 trusts developers so much and there are no types, to declare variables is not necessary. PHP syntax is made for a quick and simple solution of common problems. The entire responsibility of dangerous stunts belongs to the programmer, what in particular leads to the widespread phenomenon, as the discovering of serious errors in the code one month after delivery of the project. The sphere of PHP is not large, it is small projects, which developed by either one specialist or a closely work group . As PHP is free the language has become an ideal choice for SMB or copyrights
Speed. Theoretically, ASP.NET must run faster as we deal with once compiled binary code, whereas PHP-scripts are re-processed each time. However, PHP work on IIS and Apache with a great load (although artificially induced) and always produces better results than ASP.NET even better then .ASP classic.The ligament PHP + MySQL + Apache works better and faster than ASP.NET + IIS + Microsoft SQL Server 2000.
Does it mean that ASP.NET is worse? I don’t think so. The speed is assured that all PHP applications run in a single address space, when ASP.NET checks and double checks the data repeatedly, keeping each application in a separate address space.The first pproach is faster but less reliable, the second – is more reliable, but there is a price. Unfortunately miracles do not happen L.
About work . Briefly describe the feeling to work with PHP it is constant process of debugging this is to the fact that the language contributes serious logical errors.
Even primitive typo (highlighted in red) leads to a logical error, which would not be in C# in principle. In general, there is not any declaration of variables in PHP, which is a big minus.
Also as a rule, updating version of PHP on the server is a headache for customers and programmers. Sometimes it is very difficult to find a mistake, especially if it appears only under certain circumstances, so that it could be never revealed to the delivery of the project. It is strength and weakness of PHP. When you plan in C# and write different classes , interfaces for collections to create a page in one fell swoop for ten minutes then. In PHP you could create the page several. Still every next page is created in 10 mins on ASP.Net when in PHP you would spend the same time again and again.. If you need to change smth on the page visually, you would need 5 mins in ASP.Net, but in PHP you would need look for and change HTML.
Thus small and medium projects are fate for small groups of PHP programmers; when medium and medium and large – the inheritance of large groups, using products of Microsoft, and giant projects share between HP, IBM, Sun, Oracle, and prices are too higher, but this is another story J
Thus in conclusion I would like to notice at the beginning pace of ASP.Net development should fall sharply, then grow steadily and eventually stop at a certain level, whereas the opposite is true in PHP.
Thank you for your attention!
Elvira Golyak – Business Development Manager (LI page)
Elvira.Golyak@altabel.com | Skype ID: elviragolyak
Altabel Group – Professional Software Development
Mobile apps and HTML5 are two of the hottest technologies right now, and there’s plenty of overlap. Web apps run in mobile browsers and can also be re-packaged as native apps on the various mobile platforms. With the wide range of platforms to support, combined with the sheer power of mobile browsers, developers are turning to HTML5 as a “write one, run many” solution. But is it really viable? There are still compelling reasons to go native, and clearly, many developers are indeed going that route.
1. We can divide mobile functionality into two dimensions: the experience of the app itself, and the way it hooks into the device’s ecosystem, e.g. for Android, this would be features like widgets and notifications. In terms of app experience, native apps can do more.
2. It’s true that many in-app features are simply beyond reach for an HTML5 app. No matter how hot your web skills are, if your app is stuck in a sandbox with no camera API, it won’t be taking snaps anytime soon! Making a hybrid – native plus web – app is hardly an ideal solution. It adds complexity and applies only to web apps wrapped as native apps, rather than traditional websites accessed from a mobile browser. But it mightn’t be necessary for long. Web standards are evolving rapidly, and modern mobile browsers are keeping pace. Offline storage, geolocation, canvas graphics, and video/audio playback all enjoy widespread support among modern smarpthones, for example. Even camera is starting to be supported — as of Android 3.1, it’s possible to capture photos and videos using web standards. And the latest iOS browser supports WebSocket for 2-way streaming, as well as device orientation detection.
Overall, mobile is evolving. But the web is also evolving, and fast. Among desktop browsers alone, there are five major browser vendors evolving standards and adding features at lightning pace. While it’s not a trivial process to port these features to mobile, many of them have already made their way into the mobile browsers.
Native is a fast-moving target, but the web is closing the gap.
3. Native apps use robust programming languages (e.g. Java, Objective C, C++) which were designed for complex application development and have a proven track record. The APIs were designed ground-up to support the platform at hand. You can easily debug apps in desktop emulators which provide a close representation of the target device.
What makes web development particularly troublesome is the huge diversity of browsers and runtimes. When your app runs, it’s no guarantee feature X will be available. And even if it is, how will the browser implement it? Standards are open to interpretation. On the other hand Web is often easier to develop, especially if targeting multiple devices.
4. One of the defining features of any platform is its look and feel. Users come to expect controls to be presented consistently and manipulated in the same way. There are certain idioms which vary from platform to platform, e.g. what happens when the user performs a “long hold” (keep touching an element for several seconds)? Platforms have standard idioms for such things, and you can’t satisfy them all with a single HTML5 app.
Furthermore, platform look-and-feel is orchestrated by the platform’s native software library, whose widgets encapsulate the kind of look and feel users expect. You get a lot of the expected look-and-feel “for free” just by using the native toolkit.
5. App distribution mechanisms, like Android’s Market and Apple’s App Store, have been overwhelmingly popular in recent years and are a major driving force for the entire mobile industry. Any developer can submit their native app to the marketplace, where users can discover it through a combination of browsing, searching, and getting recommendations. Not only that, but if you’ve done your job right, the glowing ratings and comments will convince users to hit the all-important install button.
It would be nice to declare a winner here, but right now, there is no clear winner. Some apps are best suited for native and some are best suited for the web. The web stack arguably has more momentum, but in terms of capabilities and execution qualities, native apps are moving fast too. And unless there comes a time when web technologies are a first-class citizen on the majority of mobile OSs, native will always be an important consideration.