0% found this document useful (0 votes)
253 views4 pages

Fiori Code Reviewer

The document provides guidelines for developing responsive mobile apps using SAPUI5, including using controls from the sap.m library, adding comments, handling large data through pagination, and testing apps across different browsers. It also discusses best practices for code quality such as indentation, declaring variables, and handling loading states as well as performance, accessibility, localization, and testing.

Uploaded by

Ahmed Khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as XLSX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
253 views4 pages

Fiori Code Reviewer

The document provides guidelines for developing responsive mobile apps using SAPUI5, including using controls from the sap.m library, adding comments, handling large data through pagination, and testing apps across different browsers. It also discusses best practices for code quality such as indentation, declaring variables, and handling loading states as well as performance, accessibility, localization, and testing.

Uploaded by

Ahmed Khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as XLSX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Maintain Responsiveness for app which will run on mobile device

If developing a responsive app, make sure you are using the controls from sap.m library.
Do not use hardcoded strings.
Do not modify UI elements of other views
Do not hardcode username and password
Method/Function should start with comment explaining the purpose of it and the parameters. Also, it is a good practice to hav
Always use semicolon after every statement
Always declare variables with var
Always show busy indicator when some OData CRUD operation is getting executed at backend. Keep your code Intended alway
In terms of huge data, it is advisable to go for pagination with $Skip and $Top parameters of OData service.
In terms of huge data, it is advisable to go for pagination with $Skip and $Top parameters of OData service.
It’s always advisable to use callback handlers in both success as well as failure situations after an OData call.
Preview the application in different browser
Do not specify fixed size
Choose correct layout
Performance
Mobile responsiveness maintained
Controls from sap.m library used in responsive app.
No hardcoded strings.
Do not specify fixed size
No hardcoded username and password
Inline comments in the code.
Method/Function should start with comment explaining the purpose of it and the parameters.
Use of semicolon after every statement
Code Intendentation used (User Ctrl + Shift + f).
Variables declared with var
Show busy indicator when some OData CRUD operation is getting executed at backend.
In case of huge data, Pagination with $Skip and $Top parameters of OData service is used.
Use of callback handlers in both success as well as failure situations after an OData call.
Preview the application in different browser
No global variables, Use "jQuery" instead of "$"
No console.log() - use jQuery.sap.log.*
Keep an eye on performance and memory consumption, properly destroy objects when not used anymore (e.g. avoid ancestor
Apply a clean coding style adapted to the surrounding code, even though we are aware the existing code is not fully clean
Use tabs for indentation (except if the modified file consistently uses spaces)
Use variable and CSS class naming conventions like in the other files you are seeing (e.g. hungarian notation)
No global variables, of course, and use "jQuery" instead of "$"
No console.log() - use jQuery.sap.log.*
Run the ESLint code check and make it succeed
Use jQuery.sap.byId("someId") instead of jQuery("#someId") - certain characters in IDs need to be escaped for jQuery to work
Only access public APIs of other entities (there are exceptions, but this is the rule)
Comment your code where it gets non-trivial and remember to keep the public JSDoc documentation up-to-date
Controls need to be accessible (operable by keyboard and read properly by screenreaders, through ARIA support), support righ
Translation and Localization must be supported
Keep databinding in mind - users expect it to work for basically everything
Keep an eye on performance and memory consumption, properly destroy objects when not used anymore (e.g. avoid ancestor
Try to write slim and "modern" HTML and CSS, avoid using images and affecting any non-UI5 content in the page/app
Avoid !important in the CSS files and don't apply outer margins to controls; make them work also when positioned absolutely
Do not use oEvent.preventDefault(); or oEvent.stopPropagation(); without a good reason or without documentation why it is re
Write a unit test
Do not do any incompatible changes, especially do not modify the name or behavior of public API methods or properties

You might also like