SAP Syclo Inventory Manager RDS Implementation

SAP Syclo Inventory Manager RDS Implementation for a Leading Global Chemicals Company with Motorola MC9090 Rugged Handheld Devices

Traditional ERP systems were designed and built for office workers that have access to a desktop. However, within several industries, majority of their workforce are situationally away from desktops and carry out company critical tasks away from a desktop – Sales, Field Services, Warehouse and Plant Maintenance operations. These workers are disconnected from their company’s backend systems and do not have timely access to information or the ability to process information at the point of contact or occurrence.

A global leading chemical company, approached Innovapptive for a solution to connect these mobile workers and better manages their warehouse operations, to save time of their workforce, reduce errors, rework, and cut costs by connecting their employees to vital inventory and supply chain information from their SAP systems.

Background

Our client provides specialty chemicals and has operations in three continents, with over 25 plants and 75+ warehouses and was looking to replace their inefficient paper based processes and implement a mobile solution to improve productivity of their entire supply chain workforce. Our client’s operations are extremely asset intensive and require substantial MRO inventories to keep their equipment up and running. In addition, the company was struggling with an inefficient process to maintain accurate inventory levels, and also meet customer order fulfillment from their 75+ warehouses.

Given the manual and inefficient processes to maintain accurate inventory levels, and lack of visibility into up to date stock information, our client was looking for a mobile solution which would require minimal manual intervention and faster turnaround times to view or process critical inventory information.

Innovapptive Solution

Rugged Mobile Devices for Syclo Inventory Manager Mobile App

Innovapptive proposed to implement the SAP Syclo Inventory Manager Mobile solution Innovapptive’s leveraged its SAP qualified Rapid Deployment Solution (RDS) and conducted a thorough requirement gathering and GAP analysis to implement the SAP Syclo Inventory Manager App. The pre-configured Rapid Deployment Solutions (RDS) was an attractive option to the customer as it is a defined time, defined cost and defined scope putting processes to work in a much clearer position. The Innovapptive RDS is delivered with supported guides, educational material and training of the Syclo/SAP Inventory Manager app to enable end-user easy adoption into the new system. Our team installed the SAP Agentry platform and customized the SAP Inventory Manager mobile application to meet customer requirements in less than 9 weeks.

As a result of this mobile solution implementation, our customer was able to easily maintain up to date stock levels, enable their field personnel to easily locate parts, tools and material they need, thereby dramatically reducing any inherent delay of operations.

In less than 3 weeks of the roll out, the customer had the ability to immediately improve visibility across the value chain, thereby tightening their supply chain and reduce inventory carrying costs which drastically reduced any service delays and prolonged outages and failures.

Innovapptive Solution Salient Features

• Receive, issue, and transfer inventory
• Prepick, pack, and stage items
• Request, order, and install parts
• Remove parts and process returns
• Track materials by number, work order, bin, and location
• Perform inventory counts

Innovapptive Solution Results & Benefits

With the new mobile solution, implemented by Innovapptive, our customer witnessed several benefits through improving inventory accuracy and visibility, which led to optimized sales planning, thereby increasing revenue through:

• Reduced costs associated with delayed repairs
• Reduced inventory carrying costs
• Shortened or eliminate downtime resulting from part shortages
• Tightened the supply chain, service response times, and ship-to-bill cycles
• Improved workforce safety and productivity
• Improved inventory accuracy while increasing warehouse staff efficiency
• Paper-based processes were eliminated.
• Reduced errors and associated rework.
• Better service levels of maintenance workers
• Increase in overall productivity.
• Better decision making capability.
• Better accuracy of order fulfillment.
• Enhanced and optimized sales planning

For more information related to our SAP Qualified Rapid Deployment Solutions (RDS) for SAP Mobile Platform, Syclo Agentry Platform, Syclo Mobile Apps, SAP Mobile Apps, Fiori and the mPower™ Apps Suite, please contact our team byclicking here.

Appcelerator Cloud Services Impact on Mobile Server-Side Development

The cloud is truly redefining the way we work and play. In it we store our music, our pictures and movies, and our enterprise data. From it we access all of that information from laptops, tablets, smart phones, cars and TVs anywhere anytime. Of course, the mobile revolution is also delivering its fair share of transformation

When we speak with enterprise customers all the time and what we commonly hear goes something like this:

“We have many mobile initiatives and expect to roll out [tens/hundreds/thousands] of apps across multiple platforms over the next few years”

“The apps need to be of high utility and value to our [employees/partners/prospects/customers] and they need to access data from many sources including social networks, public data sources, enterprise data systems like ERP, CRM, SFA, and our custom apps”

“Our competitors have already published something similar, so we need the apps out ASAP”

“But we don’t have the time/money/resources/skills to build all the permutations of mobile client apps as well as the server-side components to support them”

“How can we prioritize one over the other, when we need both. What should we do?”

To answer this question, let me take a slight detour. Remember the good old days of client/server? Life was relatively simple then. We created a database instance with a bunch of tables and fields, hooked it up to a thick client with GUI controls and widgets, and before you knew it, our app was out the door (or more appropriately, on the desk). Network connectivity was not really an issue with LANs and the apps gave us access to the data in an acceptable form factor, on a not-so-portable, big screen, with more than enough room for extras.

But today’s mobile apps are now a complex mash-up of data from many different sources.Today’s apps need to not only look delightful on a multitude of different and smaller-sized screens, but they also need to feel great. They have to support device specific gestures and menus. They have to be cool and engaging. They need to integrate into the user’s life, so they can’t even imagine what it was like before they downloaded it.

In order to do that, an app needs automatic push notifications to update us even when we’re not in the app. We need status updates and feeds from other users so we know what’s happening. We need to “Like” things and share comments so our friends and colleagues know what we’re up to. We want to upload photos so we can share the moments of our lives. Our employees need supply chain data from the SAP system, financial data from the Oracle system and employee data from the HR system, so in that moment of need, in front of a customer or prospect, they can deliver real-time information.

So essentially what we have now are two very different sets of competing requirements – client-side applications and server-side services – both with different success criteria, different development tools and different skill sets.

And therein lies the problem – other than the biggest mega-companies on the planet who don’t have the constraints of money, people, skills, etc, the rest of us are faced with what seems like an impossible predicament.

I would suggest that of the two, the no-brainer winner has to be the client-side app. I don’t think anyone even questions the value of the user experience any more. Look at Apple. They epitomize that maniacal focus in all their products. So too does Google and Amazon.

So that leaves us with the displaced backend server-side. In order to deliver many of the above-mentioned required capabilities, “do-it-yourself” server-side development is perceived as the only solution, where you develop custom software and architectures made up of web, app and database servers to deliver these services and then integrate them to the different client apps. Then you build or provision a new infrastructure to support it all. Then wash, rinse and repeat for every new app and every time one of those data sources changes.

Fortunately there is a way out, and mobile cloud-based services offer a welcome solution. Such backend services provide the core capabilities required, over the cloud, so you can continue to focus on the client-side experience while simply consuming the backend services as needed on the cloud.

At Appcelerator we have Appcelerator Cloud Services (ACS) which offers a fast, easy, and simple way of building next generation mobile apps. With a proven set of ready-to-consume APIs, you can build beautiful apps in a fraction of the time from any mobile toolkit (of course there are numerous benefits if you use Titanium Studio too). ACS is also extensible, so it can integrate with other public services and private corporate apps to shield you from that complexity on the client.

How to migrate app to iOS 7 using Appcelerator

Apple’s recommended steps to update your application to iOS 7. iOS 7 introduces many UI changes, such as borderless buttons, translucent bars and full-screen layout for views.

THINGS EVERY APP MUST DO:

• Update the app icon. In iOS 7, app icons for high-resolution iPhone and iPod touch are 120 x 120 pixels; for high-resolution iPad, app icons are 152 x 152 pixels. (To learn more about all icon sizes, see “Icon and Image Sizes”.) Note that iOS 7 doesn’t apply shine or a drop shadow to the app icon. And, although iOS 7 still applies a mask that rounds the corners of an app icon, it uses a different corner radius than earlier versions of iOS. See the iOS 7 Icons section below.

• Update the launch image to include the status bar area if it doesn’t already do so. This is a difference of 20 pixels in height, that is, the image is stretched 20 more pixels if you do nothing.

• Support Retina display and iPhone 5 in all your artwork and designs, if you’re not already doing so.

• Titanium.UI.iPhone.createNavigationGroup

• Titanium.UI.iPhone.NavigationGroup

• Titanium.UI.iPhone.setStatusBarStyle

• Titanium.UI.iPhone.setStatusBarHidden

• Titanium.UI.iPhone.showStatusBar

• Titanium.UI.iPhone.hideStatusBar

• Titanium.UI.setOrientationModes

How to migrate app to iOS 7 using Appcelerator ?

IOS 7 BEHAVIOR CHANGES:

Button Bar and Tabbed Bar:

On iOS 7, Apple changed the style of segmented controllers, which effects what can be customized for the Button Bar and Tabbed Bar objects in the Titanium SDK. You can no longer set the background color or style of these objects. iOS 7 only supports one style and setting the tint color.

In Release 3.1.3 and later, with iOS 7 and later, when you set the background Color property for these objects, you will be setting the tint color, and the style property is ignored. For iOS 6 and prior, the background Color and style properties still works the same since these are supported on older version of iOS.

Navigation Transitions:

On iOS 7, when transitioning between two windows in a navigation stack, the bottom window slides half way off the screen,  pauses then the top window appears. This is noticeable if you do not specify a background color for your top window, which makes it transparent. As long as you specify a background color for the top window, the application will appear to transition the same as previous iOS versions.

On iOS 6 and earlier, the bottom window would slide off screen as the top window appears on screen at the same time.

Lightweight Windows:

On iOS 7 and later, all lightweight windows, including the first root window, are displayed as full screen with a transparent status bar. Lightweight windows are windows without a navigation controller, that is, not contained in a Navigation Window or Tab Group. Any view objects added to the top of the window appear behind the transparent status bar. If your UI layout relies on the top property, you may need to readjust your layout.

You can also either set the full screen property to true to hide the status bar or set the top property to 20 to move the window below the status bar to compensate for this behavior change.

Status Bar:

In Release 3.1.3 and later, the status bar is controlled by the current window that appears on screen. By default, the status bar is displayed unless you specify the Window’s full screen property to true before opening the window. You can also control the appearance of the status bar using the Window’s status Bar Style property (new API element for Release 3.1.3). These properties can also be set on any top-level container, which include Navigation Window, Split Window and Tab Group objects.

Prior to Release 3.1.3, if you created a full screen window then opened a window without specifying the full screen property. The recently opened window would also appear full screen. In Release 3.1.3 and later, since the default value is to show the status bar, the recently opened window displays.

On iOS 7, the status bar cannot be controlled on the fly with Titanium.UI.iPhone.setStatusBarStyle, Titanium.UI.iPhone.setStatusBarHidden, Titanium.UI.iPhone.showStatusBar or Titanium.UI.iPhone.hideStatusBar. You need to either set the fullscreen property to hide the status bar or statusBarStyle to change the status bar style before opening the window. In Release 3.2.0, you can use the statusBarStyle property to change the status bar style on the fly.

iOS 7 also introduces a new light content status bar style that is exposed as the Titanium.UI.iPhone.StatusBar.LIGHT_CONTENT constant in the Titanium SDK. Use this constant to specify a status bar for use with a dark background. If you want the entire application to use this style, add the following key to your tiapp.xml file.

The following API elements are obsolete or do not work on iOS 7. These elements are deprecated in Release 3.1.3 and removed in Release 3.2.0 except the setter methods.

Android App Development – Java Virtual Machine

What is a Java Virtual Machine?

The Java virtual machine is called “virtual” because it is an abstract computer defined by a specification. To run a Java program, you need a concrete implementation of the abstract specification. This blog describes primarily the abstract specification of the Java virtual machine.

The Lifetime of a Java Virtual Machine

A runtime instance of the Java virtual machine has a clear mission in life: to run one Java application. When a Java application starts, a runtime instance is born. When the application completes, the instance dies. If you start three Java applications at the same time, on the same computer, using the same concrete implementation, you’ll get three Java virtual machine instances. Each Java application runs inside its own Java virtual machine.

A Java virtual machine instance starts running its solitary application by invoking the main() method of some initial class. The main() method must be public, static, return void, and accept one parameter: a String array. Any class with such a main() method can be used as the starting point for a Java application.

For example, consider an application that prints out its command line arguments:

Code:

// On CD-ROM in file jvm/ex1/Echo.java

class Echo {

public static void main(String[] args) {

int len = args.length;

for (int i = 0; i < len; ++i) {

System.out.print(args[i] + " ");

}

System.out.println();

}

}

You must in some implementation-dependent way give a Java virtual machine the name of the initial class that has the main() method that will start the entire application. One real world example of a Java virtual machine implementation is the java program from Sun’s Java 2 SDK. If you wanted to run the Echo application using Sun’s java on Window98, for example, you would type in a command such as:

Java  Echo Greetings, Planet.

The first word in the command, “java,” indicates that the Java virtual machine from Sun’s Java 2 SDK should be run by the operating system. The second word, “Echo,” is the name of the initial class. Echo must have a public static method named main() that returns void and takes a String array as its only parameter. The subsequent words, “Greetings, Planet.,” are the command line arguments for the application. These are passed to the main() method in the String array in the order in which they appear on the command line. So, for the previous example, the contents of the String array passed to main in Echo are: arg[0] is “Greetings,” arg[1] is “Planet.”

The main() method of an application’s initial class serves as the starting point for that application’s initial thread. The initial thread can in turn fire off other threads.

Inside the Java virtual machine, threads come in two flavors: daemon and non- daemon. A daemon thread is ordinarily a thread used by the virtual machine itself, such as a thread that performs garbage collection. The application, however, can mark any threads it creates as daemon threads. The initial thread of an application–the one that begins at main()–is a non- daemon thread.

A Java application continues to execute (the virtual machine instance continues to live) as long as any non-daemon threads are still running. When all non-daemon threads of a Java application terminate, the virtual machine instance will exit. If permitted by the security manager, the application can also cause its own demise by invoking the exit() method of class Runtime or System.

In the Echo application previous, the main() method doesn’t invoke any other threads. After it prints out the command line arguments, main() returns. This terminates the application’s only non-daemon thread, which causes the virtual machine instance to exit.

The Architecture of the Java Virtual Machine

In the Java virtual machine specification, the behavior of a virtual machine instance is described in terms of subsystems, memory areas, data types, and instructions. These components describe an abstract inner architecture for the abstract Java virtual machine. The purpose of these components is not so much to dictate an inner architecture for implementations. It is more to provide a way to strictly define the external behavior of implementations. The specification defines the required behavior of any Java virtual machine implementation in terms of these abstract components and their interactions.

The block diagram of the Java virtual machine that includes the major subsystems and memory areas described in the specification . Each Java virtual machine has a class loader subsystem: a mechanism for loading types (classes and interfaces) given fully qualified names. Each Java virtual machine also has an execution engine: a mechanism responsible for executing the instructions contained in the methods of loaded classes.

When a Java virtual machine runs a program, it needs memory to store many things, including byte codes and other information it extracts from loaded class files, objects the program instantiates, parameters to methods, return values, local variables, and intermediate results of computations. The Java virtual machine organizes the memory it needs to execute a program into several runtime data areas.

Although the same runtime data areas exist in some form in every Java virtual machine implementation, their specification is quite abstract. Many decisions about the structural details of the runtime data areas are left to the designers of individual implementations.

Different implementations of the virtual machine can have very different memory constraints. Some implementations may have a lot of memory in which to work, others may have very little. Some implementations may be able to take advantage of virtual memory, others may not. The abstract nature of the specification of the runtime data areas helps make it easier to implement the Java virtual machine on a wide variety of computers and devices.

Some runtime data areas are shared among all of an application’s threads and others are unique to individual threads. Each instance of the Java virtual machine has one method area and one heap. These areas are shared by all threads running inside the virtual machine. When the virtual machine loads a class file, it parses information about a type from the binary data contained in the class file. It places this type information into the method area. As the program runs, the virtual machine places all objects the program instantiates onto the heap .

As each new thread comes into existence, it gets its own pc register (program counter) and Java stack. If the thread is executing a Java method (not a native method), the value of the pc register indicates the next instruction to execute. A thread’s Java stack stores the state of Java (not native) method invocations for the thread. The state of a Java method invocation includes its local variables, the parameters with which it was invoked, its return value (if any), and intermediate calculations. The state of native method invocations is stored in an implementation-dependent way in native method stacks, as well as possibly in registers or other implementation-dependent memory areas.

The Java stack is composed of stack frames (or frames). A stack frame contains the state of one Java method invocation. When a thread invokes a method, the Java virtual machine pushes a new frame onto that thread’s Java stack. When the method completes, the virtual machine pops and discards the frame for that method.

The Java virtual machine has no registers to hold intermediate data values. The instruction set uses the Java stack for storage of intermediate data values. This approach was taken by Java’s designers to keep the Java virtual machine’s instruction set compact and to facilitate implementation on architectures with few or irregular general purpose registers. In addition, the stack-based architecture of the Java virtual machine’s instruction set facilitates the code optimization work done by just-in-time and dynamic compilers that operate at run-time in some virtual machine implementations.

SAP Mobile Platform Licensing – Maximize your ROI

Not knowing the price of mobility can be a BIG problem. Some of the biggest challenges to implementing enterprise mobility solutions are -

• Developing a mobile strategy
• Identifying and prioritizing business cases
• Choosing a platform and mobile technologies
• Budgeting

The choice might be obvious for a lot of SAP’s customer base. With a unified solution offering under the SAP Mobile Platform, enterprises now have access to Sybase Unwired Platform, Syclo, Afaria and Netweaver Gateway. After your enterprise has spent significant resources in nailing down a mobile strategy and choosing a platform, there still are questions around cost. “How much is it going to cost in total?” In order to answer this question it is important to understand the components that make up a typical Mobile App available on the SAP store –

FIRST LAYER—THE BACK-END

SAP customers don’t need to pay additional licensing fees (beyond what they pay for their licenses already) to access the data they’re putting on their mobile devices—regardless of whether that data is in SAP or a non-SAP system.

SECOND LAYER—THE MOBILE PLATFORM

The mobile mid-tier enterprise license includes SAP NetWeaver Gateway,SUP, Afaria and the recent addition of Syclo. SAP offers various pricing options for their mobile platform, depending on the need. It is essential for enterprises to understand these options in order to maximize their investment.

Option 1: The Full License – This is a full use license and is priced per user. With the Full license the user can run any app on the SAP platform from productivity to process apps, custom or partner apps. This is the best choice for users who will use process apps as it will be more cost effective long term by allowing the user to run an unlimited number of apps on the platform. For SAP Mobile platform licensing questions as well as pricing discounts please contact sales@innovapptive.com .

Option 2: Limited Run-time License – It doesn’t make economic sense to invest in Full licenses when a user needs to use a few apps. Rather than purchase a full use license, a runtime license is purchased for each app that the user runs on SAP mobile platform.  The runtime license is priced as a % of the mobile app list price, which is a fraction of the app price. The limited run-time license is available for any SAP mobile app and SAP certified partner apps.

Option 3: Managed Mobility – This is SAP’s version of Enterprise Mobility as a Service (EMaaS). Under this license model service providers will resell the platform as a service to end customers.

THIRD LAYER—THE APPLICATIONS

There are quite a few options available when it comes to sourcing Apps for the enterprise. To see the immediate ROI, you can opt for a few pre-packaged Apps that can be purchased from the SAP Store and they have licensable user-app pricing—ranging from $ 25 to $ 1500.

A key advantage of going with the pre-packaged app is the ability to consume limited run-time licenses. This is a huge cost-savings opportunity. Lets consider the Universal Approval App which lists for $69.99 per user. Cost of licensing this app would be between $7 to $15, depending on the number of licenses. If an enterprise decides to build a similar app in-house the license cost shots up to $1,500 per user license as custom built apps are not eleigible for the limited run-time pricing. Partners will develop most of the mobile apps for SAP—approximately 80 percent of the apps, SAP recently stated.

Finally, SAP and its partners offer Rapid Deployment Services (RDS) for deploying the mobile platform and platform apps. By adhering to a fixed cost, fixed scope and fixed timeline customers are able to see immediate results through a streamlined implementation.

If you would like more information on any of the topics covered here, please email us at sales@innovapptive.com or call us at (713) 300  3762

iOS App Development: Auto Layout in iOS

Introduction to Auto Layout

Auto Layout in iOS is a system that enables you to define your app’s interface by creating a mathematical description of the relationships between the elements. You can define these relationships with respect to constraints either on individual elements or between sets of elements. You can use Auto Layout to create a dynamic and versatile interface that responds appropriately to variations in screen size, device orientation and localization.

Auto layout has become more and more important, particularly for more device screen sizes. Though Auto Layout has been available for a few years now, it has become a necessity in the current scenario, particularly for iPhone 6 or 6 Plus. Though it appears to be bit daunting to use this feature, Xcode has seen steady improvements in interface builder to enable integrating Auto Layout simpler. Starting from Xcode 6, you should learn how to use Auto Layout, wherein without using Auto Layout, it would be quite challenging to build an app that supports all screen sizes. When you use Auto Layout, you can get a stupendous control over the layout with a wide range of customization and yields the perfect interface.

Auto Layout is built into Interface Builder in Xcode 5 and is made available with apps, targeted at either iOS or OSX. If you are creating a new project, Auto Layout is enabled by default. However, if your existing project doesn’t use Auto Layout, you can adopt an auto layout.

A typical button example

Let’s assume you have a story board, where you need to place a button in the center of the view. Just run the app on both iPhone Retina (3.5 inch) and iPhone Retina (4-inch) simulators. You will notice that the button isn’t centered when running on a 3.5 inch device. Can you guess what went wrong with this?

When you don’t use Auto Layout, the UI controls (here, the button) we layout in the storyboard is at a fixed position. This implies, we “hard-code” the frame origin of the control. For instance, let’s assume that the “Click Me” button frame origin is set to (100, 185). Hence, irrespective of the screen size (3.5 inch or 4 inch) of the device you are using, iOS will draw the label in the specified position. This functionality thus explains why the “Click Me” button wasn’t displayed properly on a 3.5-inch phone, for which the screen height is different.

What you can do with Auto Layout?

Using Auto Layout in Xcode 5, you can:

• Add constraints when you are ready
• Quickly add constraints with control-drag or menu options
• Update constraints and frames separately
• Specify placeholder constraints for dynamic views
• See, understand, and resolve issues with conflicting constraints or ambiguous views

Auto Layout Concepts

The basic building block in Auto Layout is the constraint. Constraints specify rules for the layout of elements in your interface. For instance, you can create a constraint that specifies an element’s width or its horizontal distance from another element. You can add and remove constraints, or change the properties of constraints to modify the layout of your interface.

When calculating the runtime positions of elements in a user interface, the Auto Layout system takes into account all constraints at a single instance, and sets positions in such a manner that best suits all of the constraints.

The typical workflow for creating user interfaces commences by using Interface Builder to create, reposition, resize and customize your views and controls. Once you are fine with the positions and settings, you can jump start to add Auto Layout constraints to enable your interface to reach to changes in orientation, size and localization.

Adding Constraints

When you drag out an element from the object library and drop it on the Interface Builder canvas, it starts out unconstrained to make it easy to prototype your interface by dragging the elements around. If you build and run without adding any constraints to an element, you will understand that the Interface Builder fixes the element’s width and height and pins its position relative to the top left corner of the superview. This implies that resizing the window doesn’t move or resize the elements. In order to ensure that your interface reacts properly to changes in size or orientation, you need to start adding constraints.

There are numerous ways to add constraints, based on the level of precision you want and the number of constraints you want to incorporate at a time.

How to Use Auto Layout in Interface Builder?

First let us understand what Interface Builder is all about and get to know how Auto Layout can be applied:

Before we show you how to fix the alignment issue in the example, let’s have a brief walkthrough of the Interface Builder and get to know how Auto Layout can be applied.

As a first step, setup a project based on the single view application iOS app template. In the project options, click iPhone for the device family, save the project and then open the storyboard. You will notice a menu at the bottom-right corner, wherein the buttons in the menu are related to Auto Layout. You can use these buttons for alignment, sizing, spacing and resolving constraint issue. The overview of these buttons are as follows:

• Align – Create alignment constraints, such as aligning the left edges of two views.
• Pin – Create spacing constraints, such as defining the width of a UI control.
• Issues – Resolve layout issues.
• Resizing – Specify how resizing affects constraints.
• Xcode Auto Layout Menu in Interface Builder

Working with Constraints

Apart from the Auto Layout menu, Apple has made it flexible for developer to setup Auto Layout by using Control + drag. You need to just control and drag from any view to another view to set constraints between each other. Once you release the mouse, it displays a list of possible constraints for you to select them.

After you setup a constraint in a view, the constraint line is displayed in either orange or blue. The orange constraint lines denotes that there are insufficient constraints, indicating that you need to fix it.

If the constraint line is displayed in blue, it indicates that your view layout is being set up correctly and there is no confusion.

Sometimes, after you create the constraint, the Interface Builder outline view displays a disclosure arrow. The red arrow indicates that there are conflicts or ambiguities and once you click that arrow, you can view the list of issues, which are displayed on a scene-by-scene basis. Some of the core issues include missing constraints, conflicting constraints and misplaced views.

Apart from the size inspector view, the constraints also appear in the Interface Builder Outline under the corresponding view.

Conclusion

After reading this blog, you might have got an overview of what Auto Layout feature is all about and how constraints in the Interface Builder play a major role in positioning the button in a layout. Though not exhaustive in nature, the aim of this blog is to just kindle the right interest to get started using the Auto Layout feature, though my intention is to come out with much more exhaustive literature on how to use this feature with a typical implementation example in near future.

To learn more about Innovapptive’s portfolio of SAP Certified Mobile Solutions , please contact us by clicking on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.