After getting pretty far along with a jQTouch web application for our website, my boss and I decided we may as well just make a true iPhone app instead of struggling with sloppy flickering animations and login authentication issues. We currently have a fully functional web site with some SOAP web services, but we are looking at rewriting these in order to make it easier for the iPhone to call the web methods (for displaying search results, categories, and article) for our app. I have not started anything on the iPhone yet as I am not sure which direction I should be taking.
For a developer that is somewhat unfamiliar with Objective-C (I understand the basics and the syntax), what tools do you recommend to create an iPhone app that uses data from ASP.NET web methods? If everything I need is provided in the iPhone SDK, where do I start?
If you are looking to use the SOAP methods from your ASP.NET site, then use Sudzc (http://sudzc.com/).
It will generate a package with all the Objective-C source code and classes written for you, to talk to your SOAP web services. You can drop it in your iPhone project and you're good to go.
You can tweak the generated code. Huge time saver :)
Related
I know I´m late for this party.
Currently migrating form asp.net webforms to newer coding technologies and paradigms. Barely got started with asp.net mvc and now I´m noticing all this fuzz about mvc vs webapi. I'm an oldschool programmer and don´t really feel confortable with the "use both" approach, if there´s no need to. Please consider this:
My web projects focus on dynamic dashboards/admin sites to manage CRUD operations for tons of SQL records, generate reports on demand, statistics, etc.
No static websites at all (like info sites, portfolios and such).
Performance over UI design. Actually bootstrap basic UI is enough for me.
Pure ADO over entity framework, whenever possible.
Any tip or guidence on what I should choose would be very much appreciated.
* Edit/Closing *
Hi again and thank you for your feedback.
After a lot of reading and experimentation I´ve decided to give a real hard tryout to asp.net webapi + angular.js, mostly because I want to leave the door open for multiplatform/device usage (not web only).
Also, I found a very interesting article/tutorial in https://superdevelopment.com/2013/12/16/building-rich-web-apps-jquery-vs-angular-js/
It may be a little old but I think it´s worth reading, specially this extract right here: "Angular.js and WebAPI is a new way to build rich interactive web applications that fully embraces what can be done with a Web browser, JavaScript and C# rather than relying on out-dated paradigms that complicate the process for all but simple use cases. If your users and clients are expecting an application in a web browser that behaves like a native app on their desktop or smart phone, then jQuery + ASP.NET MVC is not the most straightforward way to build it."
Anyway, thanks to all and I hope this info helps others in the programming community.
if your application is going to be consumed various type of devices then prefer web api.
if your application is like website or portal where user has very little interaction then go for MVC
I have to develop a phone application on every platform so I thought of using phonegap. Seems pretty nice.
I have a web application coded in classic Asp and it's this webApplication that I need to strip down to be a phone app.
At first I thought it will be simple, my classic Asp render some html so phonegap is able to put it as an app.
But it's not that simple, because in my asp I have some code that is rendered server side, I've talked to some who tell me that some html could call the asp pages and this html could be used in phonegap. Don't think it's possible ...
Well if someone could help me here, maybe i've said something wrong in my little text don't hesitate to correct me :)
My solution (I think) : code some webServices in asp.net that will use the same database as my asp classic web application. And some html and jquery will call the webservices and those html and jquery will go trough phoneGap
What is the best way to transfer and asp classic web app to a multiplatform phone app ?
EDIT : After looking everywhere, effectively phonegap can't use asp pages. So I'm questionning myself should I do a mobile website or a mobile app with webservices?
EDIT 2: I'm going for an asp.net mobile website, someone have a great way to do this, I've seen the answer proposing mvc... more details?
You are on the correct path in wanting to use PhoneGap to create a multi-platform phone app via HTML5, and some mobile framework like jQuery Mobile.
Yes, you can leverage the power of ASP.NET to serve up your data but I wouldn't create an asmx web service. A SOAP-based service serving up XML may be too fat/overkill for your mobile web app. Instead, you may want to investigate using JSON which is more lightweight (remember, bandwidth is a concern with mobile apps). One can rapidly create an API to serve up your JSON data via the new ASP.NET Web API. With your API exposed, you can make an ajax call from your html page to retrieve the JSON and bind it using jQuery.
The bonus to using the ASP.NET Web API would be when it's time to upgrade that classic ASP web site you have there, you could leverage the API you already created.
I'd really consider rewriting the website using Mvc.Net. You may want to consider using the iUI for the views.
It will be much cheaper long-term to use modern technology than trying to shoe-horn legacy code into new usage areas.
It looks like you've made up your mind to go with a webapp instead of native apps via PhoneGap. I would recommend that you pick up this book by Jonathan Stark. It's very short - shorter than it should be when it gets into using PhoneGap - and although it focuses on iPhone development, much of the content is applicable to most mobile devices. The first few chapters give a great introduction on developing attractive, responsive, highly usable web apps for mobile devices. If you familiarize yourself with jQuery and jQTouch you can get some really great looking apps with relatively little effort, regardless of the server side technology you go with.
So i'm questionning myself should I do a mobile website or a mobile app with webservices ?
The answer to that question is always mobile website... given an outdated website that the client is wanting duplicate functionality in an app.
Do the work to convert the website or at least the portions that you need to use ajax and webservices. Once you have that in place pulling the same data to place in a mobile app will be easy... you've already done it once.
So my approach would be to convert this dataview into two separate elements Data and View.
You can probably even keep the current asp pages without a lot of modification to the code since you can still call these web-service functions the same way as before in your asp code.
Well, if you really want to reuse your existing webpage you can do the following.
Create a index.html and the body.onload event, redirect to your webpage.
Then build this index.html with phonegapbuild, and you will get your "native" application that simply loads your existing webpage.
If you want to serve mobile users, you have 2 main options:
Create a mobile website. You can render html on the server all you want, no javascript programming needed. Maybe look into jQuery mobile, it can be a cheap and easy way to make the website better for mobile users.
Create a html web app (and package it inside PhoneGap if you want). This is basically a html page which loads just the data from the server in json format and updates the page contents dynamically with javascript. You need good js skills to implement this, you're server is just a REST api that server json - technology can be anything, at least asp.net mvc makes it easy. On the client side you'll want to use some good structuring frameworks, backbone.js ( http://documentcloud.github.com/backbone/ ) is a good option. Check out http://m.linkedin.com for an example of what a mobile web app can be.
3rd hidden option: just create a native app for each platform, that'll get you the best user experience.
Over the past 6 months I've been developing web sites using asp.net. When I design something such as a contact form, 99% of the time I find myself using a script manager and update panels. Recently I tried out silverlight and expression blend, and I love it.
Is there any big cons for me to start building my forms with silverlight instead? The only big one I can think of is the user might not have silverlight and not want to download the plugin.
I guess to solve the has and has not issue, I could make a silverlight version and a standard version until it comes to the point where the plugin is as popular as flash.
Personally i would advocate doing everything in SL because i love what you can do with it. But common sense dictates otherwise. There is no point replacing relatively static webpages with a SL app. While there are methods to communicate/cooperate between SL apps and the web pages that host them, you don't really want to do this unless you have to, you can end up with quite a kludgy solution.
SL is not suitable for everything. The times you want to use it are when you can redo (or create) a whole web app (or significant chunks of it), and you want to create a more immersive and interactive desktop-like experience for the user. You also need to read up on authentication with SL and WCF services, SL navigation, and become familiar with the SL4 Out of Browser feature as it offers you some features/benefits beyond what is available to an in-broswer SL app.
The Silverlight plugin is not available in mobile devices. Also, SL 3/4 is not yet 100% supported in Linux.
You really have to take in consideration your targeted audience.
If your app is meant to be used anywhere SL or event Flash is not a good choice. None of them run on iPhones for instance.
The Silverlight platform is a good compromise between the richness of a fat client and the easy of deployment of a web app. Intranet environmentss are great candidates to take advantage of that.
The platform runs well in both Windows and Macs, and should get better in Linux too.
I am a little bit puzzled about something. I am creating a ASP.NET MVC eCommerce application and currently I have written all the back end in ASP.NET MVC.
I was thinking if its better to write all the management in WPF instead of HTML, as its probably even less prone to be exploited by hackers.
I am a Windows user so I am not really bothered about using Linux/Mac at the moment so I am quite aware that having all the back-end written in HTML will allow users to have access to the admin area using other OS.
I would like to see what are the advantages and disadvantages of having WPF to manage the content of the website as its probably much easier to develop and manage (think about Live Writer).
4-5 years ago a desktop app would probably be what you wanted to use. These days the browser is the OS and if its not on the web people just won't use it. On the web you get simplified deployment and anybody can access it anywhere. With WPF you get... shinier gradients?
"I was thinking if its better to write all the management in WPF instead of HTML, as its probably even less prone to be exploited by hackers."
An intranet website would be just as secure as a internal wpf application.
You can have combine both and make it in Silverlight (and gain most advantages and disadvantages of both - you will have a rich UI, but at cost of platform independence).
I don't think it is a very good solution for eCommerce backend though, HTML + JS can offer you all the flexibility you need and with JS libraries like jQuery is writing impressive UIs quite easy.
I personally hate platform-dependent website backends (I can recall one CMS that requiread IE 6 to work, it was total pain in the *** :) ).
Some considerations:
1) Is your team primarily made of web developers? Does it make sense for them all to learn/use WPF development?
2) How will you deploy updates to the WPF app? One thing I like about web-based internal tools is you don't have to worry about versioning/deployment so much.
3) How will you authenticate users? For an internal application that uses domain based security, I think a web app is much easier as IIS and the browser will take care of authentication/login session.
We need to build an administration portal website to support our client/server application. Since we're a .Net shop the obvious traditional way would be to do that in ASP.Net. But Silverlight 2 will be coming out of beta a good while before our release date. Should we consider building the whole website in silverlight instead, with a supporting WCF backend?
The main function of the portal will be: users, groups and permissions configuration; user profile settings configuration; file upload and download for files needed to support the application.
I think the main reason for taking this approach would be that we have good experience with WPF and WCF, but little experience in ASP.Net. Either way we would have to learn ASP.Net or Silverlight, and learning Silverlight seems a more natural extension of our current skills.
Are there any big no-nos from the experience of StackOverflowers? What are the big positives?
I would recommend against building a pure Silverlight site.
Silverlight suffers from the same issues as Flash does: Unintuitive Bookmarking, issues with printing, accessibility issues, not working back buttons and so on.
Also, you would require your users to have Silverlight installed or at least to have the ability to install it.
In controlled environements (eg. in large companies or health care) or on mobile devices, this might not be the case.
I would definitely go for a full Silverlight application, specially if you have good experience from WPF. You will be able to reuse your knowledge from WPF, and should be able to pick up Silverlight fairly quickly. I've been working with Silverlight since Beta 1, and the current Beta 2 is of solid quality. I guess it's safe to assume that a RTW version is just around the corner.
Pilf has some valid point, specially around printing. For that I would probably use SQL Reporting Services, or some other reporting framework, on the server side, and then pop up a new window with printable reports. For linking and bookmarking the issues are no different than any other AJAX application. I did a blog post today about how to provide deep linking and back-forward navigation in Silverlight.
Silverlight also has all the hooks needed for great accessibility support, as the UI Automation API from WPF is brought into Silverlight. I don't know if the screen reader vendors have caught up yet. The styling/template support in Silverlight makes it easy to provide high-contrast skins for visual impaired users if that is a concern.
Depends on your goals. If administration portal is part of application and will only be used from computers where your application is installed, there are plenty of advantages of going fully Silverlight - or even WPF.
But if you can see a scenario where it will be used either from random PC or by random person, fully functional HTML/Javascript version is absolutely necessary.
Some reasons are:
Most people don't have silverlight and you'll earn a good load of swearing if they have to download and install it. Some people who have it installed keep it disabled (together with flash and sometimes even images) to avoid distractions and speed up browsing.
When HTML site fails, user gets error page and reloads. When silverlight fails, it can hang or crash.
HTML is what is expected - both by users and web browsers: back and refresh buttons work as they should, hyperlinks and forms work as expected.
Slow internet is still very common, both in remote areas and mobile devices.
I agree with what everyone had said so far and I think this Flow Chart, which is aimed at Flash, also applies to Silverlight.
Source of Image
It sounds like your problem is that you need a rich-client admin application. Why not use click-once?
On the topic of remote andministrators, another poster stated that was an argument in favor of HTML if the admins were on a slow connection. I would argue that depending on the type of information, it may be more efficient to use Silverlight. If you have an ASP.NET datagrid populated with server side data binding, you can be downloading a ton of markup and viewstate data. Even if you're using an alrternative to DataGrid that's lighter on the ViewState, you will still have a lot of HTML to download.
In Silverlight, once you get the XAP down, which is probably going to be smaller than the corresponding HTML, the XAP is cached and so you shouldn't have that cost every time, and you'll just be retrieving the data itself.
For another example, let's say you have a bunch of dropdown lists on one of your forms which all have the same values in the list. In Silverlight, you can get these values once and bind them to all of the dorpdowns, in HTML you will have to repeat them each time.
This will get better with client side data binding in ASP.NET, which follows a very similar model to Silverlight and WPF for data binding.
Overall, I would also think that you would need to write less code for the Silverlight implementation which can increase productivity and reduce maintenace costs.
ASP all the way. You should only use silverlight/flash etc when text can't do what you want it to do - e.g. display video.
Using a plugin for your website makes it slow, and requires the user to have the plugin installed. Silverlight for instance rules out all Linux user. Also, since Silverlight is pretty new, there is no telling how committed Microsoft will be to keep the platform alive if it doesn't pick up soon.
I'd stick to plain old HTML with server side scripting.
Also, for public websites: Flash and Silverlight can't be indexed by any search engine, so good luck with writing tons of metadata if you want any visitors at all.
Silverlight is a good choice for an internal-facing portal, just as it would be for a public-facing portal if you've already evaluated your project and have decided to go forward with a web portal. You are free to integrate Silverlight components within an existing ASP.NET application (i.e. the "islands of richness") approach, but if you have the ability to build a new project from scratch, don't discount a completely Silverlight solution as a valid choice where you would have went with a traditional ASP.NET portal. Silverlight is RTW now, so if this decision is still on the table, you know you won't have to deal with breaking changes going forward.
There are some downsides with developing a site completely in Flash / Silverlight, but if those downsides won't matter to you or won't have an impact then there is nothing stopping you. Choose whatever tool you think meets your needs more fully. I wouldn't be put off creating a site purely in Silverlight based on the downsides, because it brings a lot more positives to the user experience.
The previous comments have dealt with most of the downsides of using Silverlight for a site like this and I agree. If you're determined to have rich-client style development and your audience is small (for admins only) then I'd probably recommend WPF over Silverlight as it currently provides a richer set of tools and controls.
If you stick with ASP.NET have you looked at Dynamic Data - it's ideal for building backend management sites with little effort.
I've seen "Silverlight only" websites at Microsoft and they are pretty impressive. But again, the demos were there to exploit the full potential of what Silverlight can do. The moment you need something different you may be out of luck. I don't see Silverlight like Flash except in the way they are installed/seen. But the Flash/ActionScript backend is really bad compared to what Visual Studio can offer with .NET
Ask yourself why would you like to use Silverlight? Fancy effects or programming model?