We're beginning development work on a newsreader app which pulls stories from a RESTful API in XML format. Each story contains:
Html formatted text with links to external web pages (around 1000 words per story)
1 inline advert banner (640x100)
1-10 inline images (640x320 each)
The newsreader will load 10 stories at a time when opened. It needs to be robust and performant (smooth scrolling etc).
We're considering whether to display the stories using the native UIWebView or Three20 open source library but am not sure which is the best choice. UIWebView seems to have more flexible text formatting but Three20 sounds more robust and less prone to memory leaks.
I'd appreciate any advice anyone might have from their experiences.
Thanks!
Well, the answer is: Oh, it depends.
The three20 framework offers a lot of things that you would have to do on your own - if you need these offers. If you like URL-based navigation, this might be a plus for going with three20. You mentioned flexible text formatting, which you can achieve with both approaches. three20 allows you to subclass their classes, apply styles, ...
My advice: take a deeper look in the documentation, ask yourself, if you need more than one feature that three20 offers and decide then which way to go. As with all third party frameworks, you'll have to put some effort in making things work.
Related
I am designing a web app from scratch, which would be a fluid-based layout and the same HTML would render on different screens using the adaptive CSS.
I am going to use adaptive CSS (or responsive design) for this.
I was looking to use a framework like SCSS (http://sass-lang.com/) which would improve my code maintenance efforts. I'll have lots of CSS files (and probably some skin based as well)
Since I am using adaptive layout, I am going to use CSS Media Queries for desktop/tablet/mobile CSS. I could not get an idea how well the SCSS would integrate with media queries and overall speaking , how much flexibility will it offer to me.
Please let me know your suggestions if you have used SASS/SCSS and in general, any other suggestions.
SCSS is essentially an extension to CSS, and is useful (with mixins) to void repetition in your code. It also provides a way to group blocks of CSS in semantically meaningful ways and gives you variables to avoid repeating yourself.
If you are using a framework such as Rails, it is no-brainer.
There are also frameworks which focus on layout such as 960 (and its variants), and Blueprint which also adds code for thing like buttons.
The underlying philosophy behind many of these is DRY (don't repeat yourself). One bonus of using an established framework is that many of the browser issues have been ironed out, so you can be sure that it will work cross-browser.
It is true that perhaps the code is not quite a lean as rolling your own, but with careful editing and making sure you minify the result and send it gzipped, this is not a major issue except on the most high traffic sites.
Personally I have objected to using frameworks in the past because of the small amount of additional redundant code, but after 15 years of hacking around browser issues, I now think they are a Good Thing.
Larry Wall said in Programming Perl, "We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris."
Anything that allows more people to use CSS in a repeatable and reliable way, to build on work done by other, and to try out some of the leading edge features has got be a good thing.
Engineering a site with media queries is still a bit leading edge. There are compromises in each approach and you should read up as much as possible before choosing one. Adapt.js is a good alternative if you don't mind javascript.
You may want to look into the HTML5 Boilerplate. This has some useful defaults, and lots of documentation about the HTML and CSS defaults that have been chosen.
Good luck!
I have not used media queries together with SCSS, but I don't think they conflict with each other. I have used SCSS extensively in my current rails apps, and it helped me to reduce the amount of code, and get a better understanding when to use which styles.
The tricky part will be what to have fluid (changing depending on the medias viewport size), and how to avoid repetition.
Have a look at the nice site Responsive Design with CSS3 Media Queries, to get an idea which parts of your layout may be fluid.
Have a look at 320+Susy (GitHub repo here). It uses the Susy grid framework extension for Compass. All of these tools are based on Sass and make use of media queries.
I typically work on web apps that will only be used by a small group of well-controlled people, but now find that I'm writing something that has the potential to be used by a very large population. This means that the design and "look" will be very important to the success.
While I can certainly code up something functional, it ain't gonna look pretty, so I know that I'll need to get an outside designer to make things look good. Never having worked that way before I had a few questions about the mechanics of how this happens and how to try to make things easier.
We do Java, so when building a rich interface, we use GWT. I know that when working with designers, they typically provide images of what the interface should look like without any type of "useable" output. My question is how best to bridge that gap between a simple drawing of an interface to a fully functional realized one.
Any thoughts are appreciated.
Well, "it depends", as always.
Nowadays, I don't think you can work wit someone who simply provides PhotoShop mockups. At least not at your level. Mockups are simply too static, and translating those mockups to actual pages that actually work with different browsers properly is a skill set all its own.
So, you need someone beyond simply a designer, especially if you are planning any javascript wizardry, animations, or other dynamic elements that don't capture at all well on a static image.
What you really want is an "operational" mockup. Static HTML files that look and behave as best as can be done to what the UI designer wants to do, including transitions, work flow, etc. This artifact can be run through all of the stake holders as a live mockup, letting folks "Feel" the site.
Once you have these HTML files, you can then do your part of backfilling these pages with actual server side content. Obviously you can start early working on models and working with the designers so as to have services ready to support the site functionality, but you shouldn't be committing any real time in to actual pages for the site.
As for interacting with the designers, I talk more about that over here: How can I make my JSP project easier for a designer to work with
I worked on a project very much like this. We had "comps" which were pictures of what the interface would look like. We identified common objects and build modules. Then built pages (this was for a web app) from modules plus any elements that were unique to that "comp".
A couple things to keep in mind that will make life much easier: use the comps/drawings as more of a recommendation rather than set in stone design. Try to identify common pieces early on and reuse code.
Also, designers aren't user experience gods. They often have a good idea of how things should work, but if you are close to your product and have a lot of product knowledge, don't be afraid to tweak the design as you and your group see fit. One thing that designers typically lack is product knowledge. They know a lot about general user experience and how a site should work, but they often won't know the in's and out's of your use cases and products.
If you are working with GWT, you should look for designers who are expert in CSS. Apart from, may be, the main layout of the website, all the application components like form fields, dialogs, tabs and grids etc. will need to be styled using CSS.
If the designers are not experienced in working with GWT, share the GWT's documentation about styling with them. It's a good idea to read these yourself as well. Specifically explore the GWT's theme-ing system.
Also try to make use of UiBinder as much as possible. This would allow you to stay as close to traditional HTML based design while still enjoying the GWT high level object oriented interfaces (both widgets and DOM).
Optionally you might want to tell the designers that GWT image bundles will automatically do "CSS Sprites" so they don't need to worry about page load performance issues related to images.
I've done a bit of iPhone development (3 apps in the appstore currently) but the interface has been pretty plain. I've used the stock components for the most part (UITableViewController, etc.) with a little bit of customization, but for the most part everything looks pretty generic. I'd like to get started developing apps with a richer user interface, but haven't found any good resources to get me started.
What resources have you all come across that outline how to create more advanced iOS interfaces (both iPhone and iPad)? Books? Blog entries? Just looking at the apps I have installed right now, some of the interfaces I've been very impressed with are the ESPN Score Center, XFINITY TV, Facebook, etc.
What about 3rd party interface component libraries? Are there any you recommend that provide more advanced interface components than those in the stock iOS library?
I'd love to take a look at any resources that you recommend for getting started.
I love Ray Wenderlich's tutorials. He's got one on Core Graphics which allows you to draw your own Table Views with headers, buttons, and bezier-curved footers!
Here's a little secret that often gets overlooked: a lot of the cool UI elements you see are stock Apple elements that have been customised to the brink of no return.
The main reason for this is Apple have put a lot of time and effort into making components that just plain work. A UIScrollView, for example, has had many more combined hours of testing than any app you write could hope to achieve.
The trick is to know exactly how to customise elements. A UITabBar is a good example: I've seen several apps that use their own custom tab bars. The problem is, often they don't handle edge cases particularly well. You might have issues if somebody tries to hit two items at the same time (I've actually seen an app that used their own implementation of a tab-bar crash if you pressed two items at the same time).
But if you use Apple's UITabBarController and either subclass, categorise, or otherwise overload it to get the customisation you want, you get a lot of the low-level event handling stuff for free.
You would be amazed with what you can do with a UITableViewController, and you get things like view recycling for free (some of the apps I've worked on have things like independent cell resizing, customised animation of cells, horizontal implementations of a tableview, etc).
Not a particularly useful answer, I grant you, but the point I want to get across here is once you've designed your kick-ass UI step back and consider what can be achieved with the existing toolset before rolling your own. You'll thank me when you come to bug fixing!
I also like Three20. Until now I didn't use it in my projects, but I played with it. And there's some really cool stuff in it. ;-) I think that's one way to extend your standard User Interfaces.
Another really cool part is designing your own elements. I like this really. Because you then have in your App something nobody else has. :-D
I've started looking into using Opacity for Mac, it's a pretty neat desktop application where you can generate your own graphical elements (buttons, switches, icons, etc) and then automatically generate the CocoaTouch / Quartz2D classes and headers to drop in your app ... Some elements work best when they're natively drawn on the device, rather than stored/loaded as pngs, or whatever. Moreover, you get #2x Retina display support for free. While not an interface dress-up framework, the fact that it generates Quartz2D code for you makes this a real contender for anyone who's remotely graphically creative but short on complex 2D programming skills.
Speaking of beautiful interfaces, if you're looking for inspiration or actual graphical elements to put in your interface, I frequently get some great ideas at 365psd ... they actually provide the Photoshop documents to reproduce some eye dropping UI goods, for FREE. Some places may just give you a PNG, but this does little good if you want to scale it (#2x or iPad) or customize it to fit your needs. It's like open source for graphical UI design.
Are there any major advantages/disadvantages I should take into consideration when developing an app which and deciding whether to creates parts (styled menus, pages with content with complex layout etc.) in HTML/UIWebview or doing it all native?
I would like to hear people's experiences with this.
Personally, I find that I tend to dislike web apps that are (usually) disguised as iOS apps. I tend to notice a lot of inconsistencies between the UI of a web app and a 'native' app, and most of the time, it bothers me (my biggest pet peeve is tapping a button and seeing it highlight with a little translucent black box around it like a link). Now, I don't represent the major user demographic, which probably won't care, but that's my personal opinion.
In terms of programming, I've never written a web app before, but I assume that it's going to be slightly less structured than a native app just because writing HTML, Javascript, and CSS doesn't force you to assume a certain project structure, unlike iPhone apps that have distinct views, controllers, and the like. Depending on what you want to write, this might be liberating, but can also get tangled very quickly.
As middaparka said, you can also use a mixture of the two systems if you'd like. I mean, I'm assuming you're just as good a web developer as you are an iOS developer. If you are stronger in one suit than the other, then I say that you should lean towards heading in that direction. I'd much rather see an excellently written web app than a badly written native app, and vice versa.
I suspect the major advantages/disadvantages relate to the user experience - a "native" UIKit based user interface will feel a lot more natural than manipulating items within a web view. (It'll also mean you can use more "standard" components like navigation controllers, tab bars, etc.)
That said, there's no reason not to use a mix of the two, with the main UI being implemented via the various UIKit objects and the content being provided via a web view.
I would also add that the biggest issue I've found with hybrid frameworks is that you add another dependency to your app.
For example, take a big iOS update. If your chosen framework breaks, your app breaks and you won't be able to fix it until the framework is fixed.
Also, right now there are many frameworks and you have to pray that the one you chose isn't flushed down the toilet or drops support for one of your target platforms.
Another issue is that in a web based app/component you are missing out on platform specific technologies and frameworks like core data, GCD (or any other threading model - which in web you might have do with e.g. Ajax),uitableview with caching etc.
Should you hit a wall when it comes to performance or storage,then you have many more options in the native framework.
What do you use to draw iPhone ui and write iPhone requirements specification?
I use balsamiq mockups to draw up the screens, then I write a up a page for each screen explaining behaviors
There are a number of stencils available out there for OmniGraffle and for Photoshop. I've used Omnigraffle before to create images and drop them into a Word or Pages document.
Interface Builder generally to mock up a UI, and I typically write out spec informally in notes. However, if I were submitting these to other people (i.e., a contractor or subcontractor) I'd probably be using Pages or something similar to take my informal notes, and present something formal.