July 29, 2014 at 05:02iOS vs WPF - Complicated vs. Small Soft
Friends, I didn’t come up with anything smarter than this headline, so there’s a little background.
Like all programmers, I could not help but hear about the new Swift language, which was immediately sprinkled with a variety of "helloworld" training. However, simple-looking applications are created (in my WPF-y opinion) somehow too complicated even after the introduction of the "simplified" language. Is this really necessary complexity or can they be created somehow simpler? I came across such an example of an iOS application (something like an application browser in the app) and decided to create its full analogue on the "native" WPF. The goal is to compare the complexity of the development and maybe someone will share a simpler method for iOS (if any). The abundance of screenshots will not, but the code - ... and the cat, in general, cried. So,
Task: show a list of applications from AppStor found by the specified filter. There should be an icon, title and price for each application. WPF'y example is made absolutely identical to the original, up to the same jambs, delays when loading icons.
Total, 30 lines of XAML + 44 C # code. I deliberately did not do any asynchronous, because it’s stupid to press a button and immediately change something - you need to wait for the result, but if it scratches someone, you can add 4 more lines for async / await .
In any case, the resulting code is clearly more compact and simpler than the Swift-original, and the project itself is just one form:
Well, pay attention to the work style itself - you don’t need to drag anything anywhere, adjust to someone’s “outlook on life” (see chapter “Connecting the interface” in the original) - we do what we want, at least in XAML, at least in C #.
The result is an “instantly” written application that I did not bother to pile up for 20 minutes (this, together with the analysis of the JSON response from Apple, which I first see). At the same time, just reading the iOS version dislocated my whole brain - create it there, drag it there, provide functions ... Why is it so complicated, gentlemen? With such a tool, there is certainly no desire to fill the appstore with something useful - this benefit is too expensive. Let me remind you, this is the opinion of a programmer on WPF / WinForms, so we are waiting for answers from the Apple camp!
PS
Criticism to Wellcome; first we read our words, think, then post. Thanks!
UPD
I foresaw that there would be a certain share of the “competitive effect”, but for some reason the primitive-bydlyatsky method of discussion prevails in the Russian programmer communities: “Yes, this XXX of yours sucks! Here at YYY - wow! ” Let me write again separately for those who have read only the first paragraph:
I'm not trying to fight Apple and its fans, I myself would be interested (after so many years on Windows) to learn something new (and in a well-turned up, interesting language). And when I read the lesson on creating (as it were) a simple application, I am discouraged by the difficulties Apple developers have to face, even with a modern Swift. I showed how you can make a similar application to WPF (it could be TurboPascal + Turbo Vision in general!). The WPF option seems easier to me (not without the help of the framework, of course). And against this background, I’m completely incomprehensible to the pathetic attempts to put the WPF solution as some kind of camel - it is no worse than any other solution and there is nothing “desktop” in it so that it cannot be compared with the iOS version.
So we are finishing up trying to procrastinate WPF, just suggest an SIMPLE WAY to create a similar application. If it’s not there, save the sky, I won’t blame anyone, we will assume that Apple has paid insufficient attention to the convenience of development, that's all. I am writing pis!
Like all programmers, I could not help but hear about the new Swift language, which was immediately sprinkled with a variety of "helloworld" training. However, simple-looking applications are created (in my WPF-y opinion) somehow too complicated even after the introduction of the "simplified" language. Is this really necessary complexity or can they be created somehow simpler? I came across such an example of an iOS application (something like an application browser in the app) and decided to create its full analogue on the "native" WPF. The goal is to compare the complexity of the development and maybe someone will share a simpler method for iOS (if any). The abundance of screenshots will not, but the code - ... and the cat, in general, cried. So,
Task: show a list of applications from AppStor found by the specified filter. There should be an icon, title and price for each application. WPF'y example is made absolutely identical to the original, up to the same jambs, delays when loading icons.
- We start the Studio, create a WPF application - two clicks of the mouse + give the name of the application.
- We connect the Newtonsoft.Json.dll library to the references - it will help us to parse JSON
- We supplement the XAML code of the main form with our list of applications and the input field with the button at the top.Form layout
As you can see, the code is very simple - even the element template is described in familiar terms. - We get up with the cursor on SearchButton_Clicked and press F12 - the studio jumped into the code and created a handler for us, but we will add what we need.A bit of C # magic
using Newtonsoft.Json; using System; using System.Collections.Generic; using System.Net; using System.Windows; namespace StoreBrowser { public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); } private void SearchButton_Clicked(object sender, RoutedEventArgs e) { var filter = txtFilter.Text.Trim();// подготовили фильтр if (string.IsNullOrEmpty(filter)) return; filter = Uri.EscapeUriString(filter.Replace(' ', '+')); using (var wc = new WebClient()) { // вот так двумя вызовами мы скачали JSON-ответ сервера и тут же распарсили в наши заготовленные классы var res = JsonConvert.DeserializeObject(wc.DownloadString(@"https://itunes.apple.com/search?media=software&term=" + filter)); lstApps.ItemsSource = res.results;// показываем результат } } } class StoreReply { public int resultCount; public List results;// тут сидит список наших приложений } class AppInfo { // обратите внимание - здесь далеко не все свойства приложения, мы указали только нужные нам. public string trackName { get; set; }// title public string formattedPrice { get; set; }// price public string artworkUrl60 { get; set; }// icon } }
I think it’s even unnecessary to explain how much this code is more concise than those Swift sheets on two pages loading the answer. - Well, why are we sitting? Press F5! Here is the result of the “angrybirds” filter:
Once again, I’ll pay attention if you haven’t noticed: there is not a line in the code for loading pictures - they are loaded as we scroll through the list, we just provided their URL.
Total, 30 lines of XAML + 44 C # code. I deliberately did not do any asynchronous, because it’s stupid to press a button and immediately change something - you need to wait for the result, but if it scratches someone, you can add 4 more lines for async / await .
In any case, the resulting code is clearly more compact and simpler than the Swift-original, and the project itself is just one form:
Well, pay attention to the work style itself - you don’t need to drag anything anywhere, adjust to someone’s “outlook on life” (see chapter “Connecting the interface” in the original) - we do what we want, at least in XAML, at least in C #.
The result is an “instantly” written application that I did not bother to pile up for 20 minutes (this, together with the analysis of the JSON response from Apple, which I first see). At the same time, just reading the iOS version dislocated my whole brain - create it there, drag it there, provide functions ... Why is it so complicated, gentlemen? With such a tool, there is certainly no desire to fill the appstore with something useful - this benefit is too expensive. Let me remind you, this is the opinion of a programmer on WPF / WinForms, so we are waiting for answers from the Apple camp!
PS
Criticism to Wellcome; first we read our words, think, then post. Thanks!
UPD
I foresaw that there would be a certain share of the “competitive effect”, but for some reason the primitive-bydlyatsky method of discussion prevails in the Russian programmer communities: “Yes, this XXX of yours sucks! Here at YYY - wow! ” Let me write again separately for those who have read only the first paragraph:
I'm not trying to fight Apple and its fans, I myself would be interested (after so many years on Windows) to learn something new (and in a well-turned up, interesting language). And when I read the lesson on creating (as it were) a simple application, I am discouraged by the difficulties Apple developers have to face, even with a modern Swift. I showed how you can make a similar application to WPF (it could be TurboPascal + Turbo Vision in general!). The WPF option seems easier to me (not without the help of the framework, of course). And against this background, I’m completely incomprehensible to the pathetic attempts to put the WPF solution as some kind of camel - it is no worse than any other solution and there is nothing “desktop” in it so that it cannot be compared with the iOS version.
So we are finishing up trying to procrastinate WPF, just suggest an SIMPLE WAY to create a similar application. If it’s not there, save the sky, I won’t blame anyone, we will assume that Apple has paid insufficient attention to the convenience of development, that's all. I am writing pis!