Generally this blog is more focused on the commercial aspects of mobile app solutions rather than the actual coding. But as part of the blog series on how we work at DMI here’s our minimal guidelines for coding of apps and mobile web.
The objective of guidelines is to make it easier for multiple people to work on the same code, to change entire teams over time and to make apps, mobile websites and backend functionality maintainable. These requirements should be fulfilled by every developer working for DMI permanently or temporarily or otherwise the code cannot be accepted. If one of these requirements is not applicable in a project, then this needs to be clearly motivated.
GUIDELINES FOR ANDROID DEVELOPMENT
- We use Maven for all dependency management
- We use Android best practice for localization
- Instead of creating new customised components we should always try to use existing ones from the framework if possible
- Use existing libraries for background image loading unless your own solution is proven superior
- Alleviate as much as possible the Activities from “knowing” about the UI by incorporating Fragments
Project Structure Guideline
Preferred Android project structure:
GUIDELINES FOR IOS DEVELOPMENT
- Use cocoapods for dependency management.
- Use AFNetworking for server API integration
- Encapsulate API logic into an API client.
- Use CoreData for persistence.
- Localize all strings using NSLocalizedString.
- Use folders to structure the files in the file system. Reflected in the XCode project as Groups.
- Use ARC.
Project Structure Guideline
Preferred XCode project structure:
GUIDELINE FOR WEB DEVELOPMENT
The barrier to entry for web development is extremely low and therefore discipline for web development is very important. Here are some of the most important guidelines for delivering web based projects:
- All code must be documented including meta tags and components.
- All variable names must follow standard naming convention:
Variable names can only contain letters, digits and underscores;
Variable names are case sensitive;
Do not use any hyphens (-) in your variable names;
Use meaningful names;
Be consistent in the style used;
Avoid using accented characters in variable names.
- Put Style Sheets at the Top.
- Put Scripts at the Bottom.
- Reduce Number of DOM Elements.
- Keep the code well structured .
- Do not use unnecessary libraries.
- Avoid global variables whenever possible.
- Include valid site-map when applicable.
Front End HTML
- Use a correct Doctype.
- Use a Character set.
- Use Valid (X)HTML.
- Use Valid CSS.
- Do not use unnecessary classes or ids.
- Use style sheets to control layout and presentation.
- Organize documents to be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.
- Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
- Provide a text equivalent for every non-text element (e.g., via “alt”, “longdesc”, or in element content).This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
- Provide redundant text links for each active region of a server-side image map.
- For data tables, identify row and column headers.
- Use relative rather than absolute units in markup language attribute values and style sheet property values.
- Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects, when possible.
- Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).
- Minimize HTTP Requests
- Add an Expires or a Cache-Control Header
- G-zip Components
- Configure Etags
- Optimize caching
- Minimize payload size
All the sites produced should be compatible with at least the specified browsers defined in the scope of work document. This is defined by:
- There shouldn’t be any visible or functional errors in any target browser.
- Full functionality of the service and all intended functions should be tested and working.
- Same user journey should be implemented across browser.
- Identical layouts and designs on all devices and browsers.
If any of the above is not possible then it must be clearly specified at the start of the project.
Discover our other work processes:
Image courtesy: Alex Anistratov