Author Archives: ipek
Quotes for Literary Jukebox
“To be nobody but yourself in a world that’s doing its best to make you somebody else, is to fight the hardest battle you are ever going to fight. Never stop fighting.”
E.E Cummings
“Lady I will touch you with my mind.
Touch you and touch and touch
Until you give
Me suddenly a smile, shyly obscene
(lady i will
Touch you with my mind.) Touch
You, that is all,
Lightly and you utterly will become
With infinite care
The poem which i do not write.”
E.E Cummings
“Don’t cry
-the best gesture of my brain is less than
Your eyelids’ flutter which says
We are for each other: then
Laugh, leaning back in my arms
For life’s not a paragraph
And death i think is no paranthesis.”
E.E Cummings
“But my dear man, reality is only a rorschach ink-blot, you know.”
Alan Watts
“Never use adjectives
Unless you’re trying to describe something
And you don’t want to do it the hard way.
Never use the word “forever.”
It reminds people they’re going to die
And the last thing you need is people
Distracted by their mortality during your poem.
Write what you know
Unless you’re a fool, in which case
Look to the internet, and write about
Something there.
Avoid vowels
And their angry sister
The letter Y.
Avoid cliche
On the other hand…
Learn the difference between
Epigraphs,
Epigrams and
Episiotomies.
Use as few words as possible.
In fact, hand out blank sheets of paper
And tell people it’s your finest work.
If you ever use the phrase “darkness in my soul”
Be prepared for me to come to your house and kill you.
If you’re going to write in form, do it right.
For examples, as I understand it, a haiku
Is eight hundred words written while sitting on a cheesecake.
Line breaks are important,
But use them carefully. Once you’ve
Broken a line
It’s parents will never forgive you.
Finally, go to poetry workshops.
Sometimes they serve food and you
Can’t write poetry if you’re dead
Because you forgot to eat.”
Rick Lupert “Rules for Poetry”
“We are dying from overthinking. We are slowly killing ourselves
By thinking about everything. Think. Think. Think.
You can never trust the human mind anyway. It’s a death trap.”
Anthony Hopkins
Instead of falling in love with his own image in a pond, today’s narcissist gazes adoringly at his own Facebook page.
Incommensurable values are conquering the world. If someone hurls a word into the crowd, accompanying it with a grand gesture, they make a religion of it.
“When there are no more lions,
Courage will be a man who stands up
And is arrested without fanfare
When there are no more eagles
Glory will be setting fire to parliaments
When there are no more elephants
Memory will be
A grudge passed down generations
When there
Are no more
Pumas
Gracefulness will be
Singing
An illegal song.”
“Lately I’ve been thinking about who I want to love, and how I want to love, and why I want to love the way I want to love, and what I need to learn to love that way, and who I need to become to become the kind of love I want to be…and when I break it all down, when I whittle it into a single breath, it essentially comes out like this: Before I die, I want to be somebody’s favorite hiding place, the place they can put everything they know they need to survive, every secret, every solitude, every nervous prayer, and be absolutely certain I will keep it safe. I will keep it safe.”
Andrea Gibson
“You will fall in love with someone who annoys you, whose orgasm face looks and feels pathetic. Despite all of this, there’s something keeping you drawn to them, something that makes you want to protect them from the harsh world. What you fail to realize, however, is that you are the harsh world. You aren’t their noble protector — you are someone to be protected from but it takes a lot of dates, a lot of nights where you question whether or not you are actually a good person, for this to ever resonate with you. When it’s over and whatever love is left is put back in the fridge like a sad plate of leftovers, you will finally understand that you have the power to hurt someone. You can either hurt them or love them and it’s up to you to decide what kind of role you would like to take on in future relationships. What feels more comfortable — being the one who loves more or being the one who’s loved less?
You will fall in love with someone who’s cold and always seemingly pushing you away. When all is said and done, they will be forever known as the one person you couldn’t get to love you. Unfortunately, it will hurt and sting worse than the good ones, the ones that chopped up your meat for you and picked out an eyelash from your eye and were nice to your mother, because love often feels like a game we need to win. And when we lose, when we realize we couldn’t get what we ultimately desired from a person, it makes us feel like a failure and erases all the memories of those who loved us in the past. It’s a permanent smudge on your love resume.
You will fall in love with someone for one night and one night only. They’ll come to you when you need them and be gone in the morning when you don’t. At first, this will make you feel empty and you’ll try to convince yourself that you could’ve loved this person for longer than a night, but you can’t. Some people are just meant to make cameo appearances, some are destined to be a pithy footnote. That’s okay though. Not every person we love has to stick around. Sometimes it’s better to leave while you’re still ahead. Sometimes it’s better to leave before you get unloved.
You will fall in love with the old couple down the street because to you they represent the impossible: a stable, long-lasting love. You’re trying to get someone to like you for more than ten minutes. A monogamous “never get sick of ya” love seems unfathomable. “What’s your secret, sir? Do you just say yes a lot?”
You will fall in love with smells, the good and the bad kind. You will want to wear your lovers shirt because it makes you feel close to them and you’re okay with being that PSYCHO who is legitimately sniffing their shirt in public. You will fall in love with sweat, certain perfumes, the smell of the season in which you fell in love. This particular love smells like fall. It smells like Halloween and a roaring fire and leaves and fog and mist and candy and food and family and whiskey and sex and the lint that collects on sweaters. When it ends, if it ends, you will never experience another fall without thinking of him, her, it. The memories will stick to the ground like a mound of leaves and will only dissipate when the weather drops.
You will fall in love with your friends. Deep, passionate love. You will create a second family with them, a kind of tribe that makes you feel less vulnerable. Sometimes our families can’t love us all the time. Sometimes we’re born into families who don’t know how to love us properly. They do as much as they can but the rest is up to our friends. They can love you all the time, without judgement. At least the good ones can.
This is where I’m supposed to tell you that you will fall in love with The One, a person who isn’t too cold or too nice. Their “O” face is perfectly fine and they’re not afraid to show how much they love you. This person is supposed to wait for us at the end of the twentysomething road as some kind of reward for all the heartache and loneliness. We deserve them. We’ve earned this kind of love.
So fine. You’re going to fall in love with The One. You’re going to fall in love with someone who will make sense beyond college or a job or a particular season. They’ll make sense forever and won’t ever want to leave you behind. I’m telling you this not because it’s true but because it NEEDS to be true. Everyone is entitled to this kind of love, so why not? Have it. It’s yours. Blow out the candles on your 30th birthday, holding their hand, and let out an exhale that’s been waiting for ten years. Do it. Now.”
The Types of People You Will Fall in Love With In Your 20s by Ryan O’Connell
“The average daydream is about 14 seconds long and we have about 2000 of them per day. In other words, we spend about half of our waking hours — one-third of our lives on earth — spinning fantasies.”
The Storytelling Animal
“Everything is more beautiful
because we’re doomed.
You will never be lovelier than you are now.
We will never be here again.”
Homer, The Iliad
“Dividing the number of atoms in the entire atmosphere by those in one breath shows that about 1 in every 2 x 1021 atoms we breathe in the air right here is from Cleopatra’s dying exhalation (assuming, reasonably enough, that winds over two millennia have done a thorough worldwide mixing job). This, in turn, means that each of us inhales about 40 atoms — say 20 molecules — from her last gasp with every breath we take.”
Cleopatra’s Last Breath
“It’s dark because you are trying too hard. Lightly child, lightly. Learn to do everything lightly. Yes, feel lightly even though you’re feeling deeply. Just lightly let things happen and lightly cope with them. I was so preposterously serious in those days… Lightly, lightly – it’s the best advice ever given me…So throw away your baggage and go forward. There are quicksands all about you, sucking at your feet, trying to suck you down into fear and self-pity and despair. That’s why you must walk so lightly. Lightly my darling.”
Aldous Huxley
THE REAL GUIDE TO IOS APPLICATION DESIGN Part – III
In the previous posts I wrote about a counter unit system against Apple’s 44-pixel rhythm. And today I would like to demonstrate on how to effectively use it.
Ofcourse all starts with what we Turkish people call ‘amele işi’ which is to say the idiots way of doing the hard work. But I like to start that way just to permanently have it at the side.
By now you know of the 4 pixel unit system I have proposed. If not, then I urge you to read the previous two posts I have uploaded.
Basically I proposed to divide the grid in 4 pixel units, that harmoniously works with apple native elements and produces better results in every aspect of the design. And now to implement it the easy way and the hard way.
First is the hard way, because I spent many hours trying to figure the 4 pixel unit system and alas only to find out very few people also did. And in the process spent countless hours with the photoshop grid and guides and therefore it may be good practice for you as well.
Open your Photoshop and make your canvas size 640 x 960 pixels. It is always better to work double canvas for retina display rather than working in original 320 x 480 and then multiplying by 2. Why? Well because if you’re working every shape with vector that may be fine but if there are any photoshop styles involved the produced resulted when multiplied will not be to your liking and they will %99 loose their crisp and shiny look. On the other hand the only bad side of working x2 is that you have to import finished page to your iPhone and look to find that the font is a bit out of scale or the button and you know exactly how many pixels to reduce it after a while.
So this is your canvas, say hi! And let’s get to work. Go to View on your above navigation and Click on View Guides. Cmd-R produces same result. Then make sure your zero point is exactly at the corner, then magnify by 600 or more and start putting a ruler guide in every 4 pixels! Hahahaha told you it was amele işi 🙂
Here is the result you should achieve.
In 100%
In 200%
In %3200
Notice how everything looks like the perfect grid? It is. And we will further demonstrate it. But before that I will also give you the easy way of working this grid.
HOW TO EASE THIS GRID WHEN DESIGNING
Okay so you have your perfect grid. But there is still a problem. Working with it. After a while you’ll realize it is almost painful to work this way, even if you open your ‘snap to grid’ option because your app will the pixel perfect you count everything and to count your 4 pixel units you find yourself working in 3200% zoom.
Double clicking your rulers will open your preferences, where you can change the color of your grids but let me tell you before hand it is not gonna work out.
Here is my solution.
Keep your grid but Cmd-H it and make it invisible while working, only to view them when necessary. all the while don’t forget the ‘snap to guide’ option turned on at all times.
Then open Illustrator! A designer’s best friend!
Always say hi to your canvas.
Then click on you line segment tool twice. Line Segment Tool Options will open.
To length punch in your canvas size 640 pixels, and click okay. This will produce one perfect line. But it will be a line and you don’t want a line so expand it into and object, and it will quickly become 1 pixel line object.
Then go ahead and click on rectangle tool twice to again open the options window and punch 4 pixels to 4 pixels. Place the square to the head of your canvas and then place your line directly above it.
Thats all you have to do as the rest is just Cmd-D as it will repeat your last action. Voila hold Cmd-D for a few seconds and all of your canvas is filled with your guide.
Now group that and copy-rotate 90 degrees. ho ho you got it.
Now range the color of your guides to a hue that your eyes won’t tire and export the document to photoshop and always keep it a top layer. Your objects will snap to your grid and when you want to have a close look the colors won’t tire your eyes!
THE REAL GUIDE TO IOS APPLICATION DESIGN Part – II
Previously I wrote about how Apple’s and Clark’s 44-pixel rhythm had loopholes that could not be ignored. In this post I will write about a system that does work.
After realizing the problems with Apple’s harmony, I searched through books, applications and the internet for a solution. Tried some of them to find that it was not for me. The day I took matters to my own hand and started calculating was the day I also find another designer with the same solution.
You should be warned ahead, although the scale harmony I’m about to write is a solution to all your problems it is not that easy to work with. It requires immaculate designing, and a pre based layer in your software (photoshop illustrator) so that you don’t get lost in zooming in and out of your guidelines.
THE 4 PIXEL RHYTM UNIT
Nothing more, nothing less. 2 pixels would make you go crazy and 6 or 8 just doesn’t divide folks. 4 pixels as a basic unit and that’s it.
Why?
1- Both the width and the height of the iPhone and even iPad screen can be divided by 4.
2- Using 4 pixels as basic unit, we can construct horizontal and vertical grids with equal parts of 4, 8, 16 and 32-pixel intervals. Talk about flexible!
And now onto the more beauties of 4 pixel unit system!
From our previous case studies you remember how it was impossible to divide 44 pixels into current native elements. Such was the case of status bar which was 20 pixels in height. Now it can divide!
The height of buttons can be bumped from 30 to 32 pixels. The tab bar can drop a pixel to 48-pixels tall. The navigation bar with prompt can be 72-pixels tall instead of 74. Grouped table cell height can remain at 44 pixels. Distances between section headers and table groups can be multiples of 12!
With the vertical and horizontal intervals being equal, square elements can be easily laid out. For example, profile pictures and icons. And they usually come in standard sizes that are multiples of 4. Social networks like Facebook and Twitter often use default 48 × 48 avatars. Computer icons like those on Windows and OS X had always come in 16 × 16, 24 × 24, 32 × 32, 48 × 48 and up to 256 × 256 and 512 × 512 sizes. All multiples of 4. Icons in iOS can therefore stick to standards sizes and save developers time and effort recreating their icons at odd sizes.
And now let’s view the prima vera of application design to show you the difference.
Above is the iPod playlist currently proportioned by Apple:
(Look close, I chose this page in particular because it’s really clustered)
And here is the 4 pixel unit system playlist re-designed. The iPod playlists screen contains cells that have two lines of text in them. To avoid using small text and clutter, the cell height was increased to 46 pixels. Here the visual rhythm totally loses its integrity. How about we use 48-pixel cells instead of 44 or 46?
The playlists text shares the same left alignment as the light grey buttons. The increased space around the text also improves the readability and scannability. The light grey buttons and navigation bar buttons share the same height at 32 pixels. The result is a much more visually stable layout, no?
HERE IS THE COMPARISON ONCE AGAIN
You may notice that the 48-pixel rhythm had caused the grey text of the last playlist to be cut off. This is not a problem because users rarely stare at a static screen from top to bottom. It’s easier to fixate a small area than the whole screen thus the usual behavior is that users would scroll the screen and move information from the bottom to the the upper regions of the screen where their eyes are fixated. Therefore it is more important to improve scannability even at a slight expense of information density!
On my next post I will give further examples from the applications that I am currently working on and from Literary Jukebox.
THE REAL GUIDE TO IOS APPLICATION DESIGN Part – I
Those who have stepped into the world of application design either did it blindly or with the guide of Josh Clark. Any designer that studied application design in terms of user interface and grid lay-out know these words by heart;
“The 44-pixel block is, in many ways, the basic unit of measurement for the iPhone interface, establishing the visual rhythm of many iPhone apps. That metric is significant as the recommended minimum size to make a tap target (like a button or list item) easily and reliably tappable.”
The quote above is from Josh Clark’s book Tapworthy, an authoritative book on iPhone UI design. And his words were confirmed by Apple in their Mobile HIG ( Human Interface Guidelines) as they did recommend 44 x 44 pixels as the most comfortable minimum size for tappable UI elements. Many app, if not all, you see today work with the 44-pixel rhythm which I will further explain in this post. And everyone seems satisfied. Yet a few is skeptic, and I am one of them.
Since I have started designing iPhone apps, I have always looked for information on how to properly and best work the user interface. First you read the Apple’s guideline, think of it as primary schooling in application design. You have to first learn how the screen in front of you works. How it was divided, what is the dimensions and scales the provider itself uses. And then you COPY.
Think of it as the first days of school and they are tell you this is a notebook and here is the pen it lets you draw on the notebook, and what are going to draw? Well, the alphabet! And you copy all the letters until which is a long time after by the way, you realize you don’t need to draw on the notebook, nor do you need to draw with a pen and what is this alphabet they are talking about…
The very same way, after Apple’s guidelines, you learn what is what and make meaning of them. And you’re ready for further research. Since the internet is very giving most don’t need further research. You can find already made photoshop and vector files and practically change the color and places of two buttons and voila you have an application. And there are thousands of applications like this believe me.
Then you read Tapworthy and it is like a revelation. But it doesn’t change the system. It takes it as perfect and plays inside it. The grid, the scale everything is the same. And frankly after a while you realize it was the false epiphany.
Why? Here is why,
Apple’s intention of using 44-pixel rhythm is clearly to denote a fixed vertical interval equivalent to a baseline grid – a very common technique in print design. The purpose of a baseline grid is to provide a master backbone for text to adhere to. and everything takes root from there. It is usually equal to the leading of the main body text and the leading for other text e.g. headings and block quotes are usually derived from multiples of the baseline grid. This gives the text layout a stable visual composition. The problem with 44 pixels is that it hardly qualifies as a valid rhythm.
Don’t believe me? Let’s examine the 44-pixel rhythm closer.
CASE 1: GROUPED TABLES
For example in an interface made up of grouped tables, the rhythm is further subdivided into four intervals of 11 pixels each. This provides the spacing between section headers and between table groups. We can thus say the iPhone screen layout follows a major rhythm of 44 pixels and a minor rhythm of 11 pixels. This rhythm pair forms the basis of the visual composition.
The available size of a iPhone screen is width 320 × height 460 pixels at portrait orientation after excluding the status bar, or points if we are talking about the Retina display. If you divide 460 by 44 you get a remainder of 20. Divide by 11 and you get a remainder of 9. 460 cannot be divided into equal parts of 11 nor 44. The vertical rhythm is corrupt.
This is how 44-pixel rhythm works:
Is it not a poorly constructed baseline grid? It makes you do lots of compromises without even realizing.
CASE STUDY 2 : STATUS BAR
The status bar on both iPhone and iPad is 20 pixels tall which means it also does not fit into the ”vertical rhythm of 44-pixels”. As you all know, tapping on the status bar scrolls the screen back to the top. Pulling down on it reveals the notification center in iOS 5. It’s a really small tap area though and most of us ‘accidentally’ does it. On one hand it is clever, because using almost no pixel space we are programmed to to use by scrolling our fingers from out of the screen towards inside thus activating. Hypocrite, yet perhaps great intelligence behind it. Apple says the minimum is 44 yet makes us make use of 20 pixels…Yet it still doesn’t work with me.
CASE STUDY 3: 29-PIXEL BUTTONS
Buttons on the navigation bar, toolbars and table cells are 29 pixels tall and by now you know that doesn’t fit with the 44-pixel rhythm as well. A major mistake is usually done here in between programming and designing. How?Apple may make their buttons 29 pixels in height but their tappable area is always 44 pixels ratio. Yet when people copy from the internet and paste the buttons to their designs and then send the design to programming, usually the programmer slices the area to 30-35 pixels most for the tappable area and that is left to their judgement and if you’re lucky. If you are not so lucky with your programmer you’re left with a 29 pixel tappable area which results in bad and poor application whose buttons are always problematic.
In this case study I have to note that usually buttons without border work so much better as their tappable area is invisible and wider thus allowing a better user interface.
CASE STUDY 4: 49 PIXEL TAB BAR
Tab bar is among the main attires of the application design. It consists of icons stacked above text labels which need to be accommodated with additional height. 49 pixels of black tab, talk about ugly. No wonder applications like Twitter has abandoned the native tab bar long ago even before they became twitter. In 49 pixels height this main artery also does not fit with the 44 pixel rhythm.
CASE STUDY 5: PIXEL NAVIGATION BAR WITH PROMPT
When the prompt option is turned on in a navigation bar in iPhone, the bar becomes 74 pixels tall. And guess what? Yet again it does not fit with the 44-pixel rhythm!
So you see folks, apple may tell you to go with 44 pixel design scale rhythm but they lay out and the visual integrity barely holds itself together.
In the next part I will be talking about a solution to work in harmonious proportions that application design needs very much so.
LJ – Layout Map
Ruby on Rails Tutorial Edition 2
I have bought the Ruby on Rails Tutorial PDF from http://ruby.railstutorial.org/
The pdf costs 26 dollars, for any other friend who would like to use it, I’m attaching it below.
There is also video tutorials but they cost more than 100 dollars so I decided it would be better to first try and understand the pdf, and if I still have problems then I plan to buy the Screencast of Ruby.
Unfortunately I couldn’t upload the pdf due to the fact that it exceeds the limit. For anyone who would like to get the pdf, I can send by email.
As you can see it’s 500 pages so it will take a while.
Page Sketches
Link Glossary And Reading List
I have created pdfs from the best of website arguments on the topics I have problem with and I wanted to share their pdf form in case there are those who likes to read even if there is no internet 🙂
the-fight-gets-technical-mobile-apps-vs-mobile-sites
Mobile Web App vs. Native App It’s Complicated
LINK GLOSSARY
RUBY ON RAILS BY SMASHING MAGAZINE
http://mobile.smashingmagazine.com/2012/08/02/get-started-writing-ios-apps-with-rubymotion/
RUBY ON RAILS FORUM DISCUSSIONS
http://www.sitepoint.com/forums/showthread.php?852418-Ruby-and-Rails-esque-development-on-iOS
NATIVE VERSUS WEB IOS APPLICATIONS
http://mobithinking.com/native-or-web-app
NATIVE VERSUS WEB IOS APPLICATIONS – FORBES
http://www.forbes.com/sites/fredcavazza/2011/09/27/mobile-web-app-vs-native-app-its-complicated/
NATIVE, HYBRID OR WEB APPS?
http://buildmobile.com/native-hybrid-or-web-apps/
Questions And Answers on Application Design – Ruby on Rails
So, since I had many questions I gathered them around and looked for the answers that we will debate in class this week. Here they are:
- What is application database backend?
A back-end database is a database that is accessed by users indirectly through an external application rather than by application programming stored within the database itself or by low level manipulation of the data.
A back-end database stores data but does not include end-user application elements such as stored queries, forms, macros or reports.
- What is Ruby on Rails?
http://rubyonrails.org/
Ruby on Rails, often shortened to Rails, is an open source full-stack web application framework for the Ruby programming language. Ruby on Rails runs on the general-purposeprogramming language Ruby, which predates it by more than a decade. Rails is a full-stack framework, meaning that it gives the web developer the ability to gather information from the web server, talk to or query the database, and render templates out of the box. As a result, Rails features a routing system that is independent of the web server.
Ruby on Rails emphasizes the use of well-known software engineering patterns and principles, such as Active record pattern, Convention over Configuration, Don’t Repeat Yourself andModel-View-Controller.
Like many web frameworks, Ruby on Rails uses the Model-View-Controller (MVC) architecture pattern to organize application programming.
In a default configuration, a model in a Ruby on Rails framework maps to a table in a database. By convention, a model named User will map to the database table users, and the model will have a filename user.rb within app/models. While developers can choose to use whatever model name and database table name they wish, this is not a common practice and it’s usually discouraged because Rails philosophy is to use convention over configuration.
A controller is the component of Rails that responds to external requests from the web server to the application, and responds to the external request by determining which view file to render. The controller may also have to query the model directly for information and pass these on to the view. A controller may provide one or more actions. In Ruby on Rails, an action is typically a basic unit that describes a single rule on how to respond to a specific external web-browser request. Also note that, if a controller/action is not mapped to the Rails router, the controller/action will not be directly accessible by external web requests. Rails encourages developers to use RESTful routes, which include actions such as: create, new, edit, update, destroy, show, and index, as these are routed automatically by convention in the routes file if specified.[clarification needed]
A view in the default configuration of Rails is an erb file. It is typically converted to output html at run-time, although, in theory, any format can be used as a view.
Ruby on Rails includes tools that make common development tasks easier “out of the box”, such as scaffolding that can automatically construct some of the models and views needed for a basic website.[21] Also included areWEBrick, a simple Ruby web server that is distributed with Ruby, and Rake, a build system, distributed as a gem. Together with Ruby on Rails, these tools provide a basic development environment.
Ruby on Rails relies on a web server to run. Mongrel was generally preferred over WEBrick at the time of writing,[citation needed] but it can also be run by Lighttpd, Apache, Cherokee, Hiawatha, nginx (either as a module – Passengerfor example – or via CGI, FastCGI or mod_ruby), and many others. From 2008 onwards, the Passenger web server replaced Mongrel as the most-used web server for Ruby on Rails.[22]
Ruby on Rails is also noteworthy for its extensive use of the JavaScript libraries Prototype and Script.aculo.us for Ajax.[23] Ruby on Rails initially utilized lightweight SOAP for web services; this was later replaced by RESTful web services. Ruby on Rails 3.0 uses a technique called Unobtrusive JavaScript to separate the functionality (or logic) from the structure of the web page. jQuery is fully supported as a replacement for Prototype and, in Rails 3.1, is the default JavaScript library, reflecting an industry-wide move towards using jQuery. Additionally, CoffeeScript was introduced in Rails 3.1 as the default Javascript language.
Since version 2.0, Ruby on Rails offers both HTML and XML as standard output formats. The latter is the facility for RESTful web services.
Rails 3.1 introduced Sass as standard CSS templating.
By default, the server uses Embedded Ruby in the HTML views, with files having an html.erb extension. Rails supports swapping-in alternative templating languages, such as HAML and Mustache.
Ruby on Rails 3.0 has been designed to work with Ruby 1.8.7, Ruby 1.9.2, and JRuby 1.5.2+; earlier versions are not supported.[24]
Rails 3.2 series is the last series to support Ruby 1.8.7.
Framework structure
Ruby on Rails is separated into various packages, namely ActiveRecord (an object-relational mapping system for database access), ActiveResource (provides web services), ActionPack, ActiveSupport and ActionMailer. Prior to version 2.0, Ruby on Rails also included the Action Web Service package that is now replaced by Active Resource. Apart from standard packages, developers can make plugins to extend existing packages. Rails 3.2 deprecates the old plugins Rails 2-3-stable style in which plugins are to be placed under vendor/plugins, in favor of packaged gems.[25]
[edit]Deployment
Ruby on Rails is often installed using RubyGems, a package manager[26] which is included with current versions of Ruby. Many free Unix-like systems also support installation of Ruby on Rails and its dependencies through their native package management system.
Ruby on Rails is typically deployed with a database server such as MySQL or PostgreSQL, and a web server such as Apache running the Phusion Passenger module.
There are many Ruby on Rails web hosting services such as Heroku, Engine Yard and TextDrive.
- Why am I favoring towards Rails?
In the forums I have learnt that applications such as twitter and badgeville were created using Rails. And that Facebook is actually upset that they they have chosen to write on php and changing everything while trying to correct their mistake, they created their own language.
- How do I plan to connect Rails?
From what I gathered I will built up a website that will be the application screens to connect Rails with html5. This website will be in the resolution fit for my application. I will then write the page motor with Javascript to have real time interaction, touch gestures. For page designs I will be using css3 stylesheet. Then in Xcode I will capture the whole screen and connect it with the website. Which will make it an web application in the disguise of a native iOS app.
Native App vs. Mobile Web App
One of the things you’ll need to decide early on in your mobile application development process is how you’ll build and deploy your app. There are two main directions you can go: native app or mobile web app. In this article, we’ll talk about the differences between the two so you can make an informed decision.
Native App vs. Mobile Web App: Definition
First, let’s define what we mean in this article when we say “native app” and “mobile web app”.
What is a Native App?
A native app is an app for a certain mobile device (smartphone, tablet, etc.) They’re installed directly onto the device. Users typically acquire these apps through an online store or marketplace such as The App Store or Android Apps on Google Play.
Examples of native apps are Camera+ for iOS devices and KeePassDroid for Android devices.
What is a Mobile Web App?
When we talk about mobile web apps in this article, we’re referring to Internet-enabled apps that have specific functionality for mobile devices. They’re accessed through the mobile device’s web browser (i.e. on the iPhone, this is Safari by default) and they don’t need to be downloaded and installed on the device.
Comparison of Native App vs. Mobile Web App
Let’s do a quick rundown and evaluate native apps versus mobile web apps under these factors:
- User interface
- Development
- Capabilities
- Monetization
- Method of delivery
- Versioning of the app
- Strengths
- Weaknesses
User Interface
Some companies choose to develop both a native app and a mobile web app. Here’s a side-by-side look at Facebook’s native app and mobile web app:
Notice that, in terms of the general look-and-feel, there’s little difference between the two, making for a consistent user experience.
Development
Native Apps | Mobile Web Apps |
---|---|
Each mobile application development platform (e.g. iOS, Android) requires its own development process | Runs in the mobile device’s web browser and each may have its own features and quirks |
Each mobile application development platform has its own native programming language: Java (Android), Objective-C (iOS), and Visual C++ (Windows Mobile), etc. | Mobile web apps are written in HTML5, CSS3, JavaScript and server-side languages or web application frameworks of the developer’s choice (e.g. PHP, Rails, Python) |
Standardized software development kits (SDKs), development tools and common user interface elements (buttons, text input fields, etc.) are often provided by the manufacturer of the platform | There are no standard software development kits (SDKs) that developers are required to use to make a mobile web app |
There are tools and frameworks to help in developing apps for deployment on multiple mobile OS platforms and web browsers (e.g. PhoneGap, Sencha Touch 2, Appcelerator Titanium, etc.) |
Capabilities
Native Apps | Mobile Web Apps |
---|---|
Can interface with the device’s native features, information and hardware (camera, accelerometer, etc.) | Mobile web apps can access a limited amount of the device’s native features and information (orientation, geolocation, media, etc.) |
Monetization
Native Apps | Mobile Web Apps |
---|---|
Mobile-specific ad platforms such asAdMob (though there can berestrictions set by the mobile device’s manufacturer) | Mobile web apps can monetize through site advertisement and subscription fees |
Developers have the ability to charge a download price and app stores will typically handle the payment process (in exchange for a percentage of sales) | Charging users to use the mobile web app requires you to set up your own paywall or subscription-based system |
Method of Delivery
Native Apps | Mobile Web Apps |
---|---|
Downloaded onto a mobile device | Accessed through a mobile device’s web browser |
Installed and runs as a standalone application (no web browser needed) | No need to install new software |
Users must manually download and install app updates | Updates are made to the web server without user intervention |
There are stores and marketplaces to help users find your app | Since there is no app store for the Mobile Web, it can be harder for users to find your app |
Versioning of the App
Native Apps | Mobile Web Apps |
---|---|
Some users may choose to ignore an update, resulting in different users running different versions of the app | All users are on the same version |
Strengths
Native Apps | Mobile Web Apps |
---|---|
Typically perform faster than mobile web apps | Have a common code base across all platforms |
App stores and marketplaces help users find native apps | Users don’t have to go to a store or marketplace, download the app and install the app |
App store approval processes can help assure users of the quality and safety of the app | Can be released in any form and any time as there isn’t an app store that has to approve the app |
Tools, support and standard development best practices provided by device manufacturers can help speed up development | If you already have a web app, you can retrofit it with a responsive web design |
Weaknesses
Native Apps | Mobile Web Apps |
---|---|
Are typically more expensive to develop, especially if you’re supporting multiple mobile devices | Mobile web apps can’t access all of the device’s features (yet) |
Supporting multiple platforms requires maintaining multiple code bases and can result in higher costs in development, maintenance, pushing out updates, etc. | Supporting multiple mobile web browsers can result in higher costs in development and maintenance, etc. |
Users can be on different versions and can make your app harder to maintain and provide support for | Users can be on different mobile browsers and can make your app harder to maintain and provide support for |
App store approval processes can delay the launch of the app or prevent the release of the app | For users, it may be harder to find a mobile web app because of the lack of a centralized app store (though listings do exist such as Apple’s Web apps and you can request to be listed in them) |
Native App vs. Mobile Web App: How Do You Choose?
To help you decide how you should build your mobile app, ask yourself these questions:
- Does the mobile app require the use of any special device features (i.e., camera, the camera’s flash, accelerometer, etc.)?
- What’s my budget?
- Does the mobile app need to be Internet-enabled?
- Do I need to target all mobile devices or just certain devices?
- What programming languages do I already know?
- How important is speed and performance?
- How will this app be monetized effectively?
Answering these questions can help you make an informed decision.
Conclusion
Whether you decide to build a native app or a mobile web app depends on many factors: business objectives, target audience, technical requirements and so on.
You don’t necessarily have to choose between building a native app or a mobile web app. As mentioned earlier, companies like Facebook maintain both native apps and a mobile web app. However, for many of us, budget and resource constraints will require us to decide if we need to build a native app or a mobile web app (or, at least, will require us to prioritize which one to develop first).
Might Be Useful for Friends – Mrmr – OPEN MOBILE TOUCH PROTOCOL
What is Mrmr? I just found it by accident and thought it might be helpful to some of my friend’s projects.
First the link: http://mrmr.noisepages.com/4-2/
Mrmr is an ongoing open-source research project to develop a standardized set of protocols and syntax conventions to control live installations and multimedia performances via mobile devices. The project is currently spearheaded by Eric Redlinger, researcher-in-residence at Brooklyn Polytechnic University’s Integrated Digital Media Institute.
Simply put, Mrmr is a technology that enables you to use ordinary cell phones and PDAs as controllers in audio-visual performances, or to participate in interactive museum exhibits, or to use your mobile device in the place of the mouse or trackpad from your full-size comp. |