This is my first time working with eCommerce Application - mobile app for iOS. Previously I have worked in developing many iOS applications - products and business based applications, banking domain, etc. Where, usually data is available at the client server and the communication happens through REST/SOAP services - parse the response - update the UI. I am familiar with this scenario.
I am just walking through the functional document for developing the eCommerce App, I found that they use CQ5 and Hybris as the backend systems.
I am wondering what is the role of CQ5 and Hybris here. In what ways it helps in managing an eCommerce application?
I guess they are for admin purpose. Being an iOS developer, how far I should know about them?
Hybris is the ecommerce system, and CQ5(now Adobe AEM) is the Content Management System (CMS) and Digital Asset management (DAM) portion. Hybris acts as the payment processor and inventory management. From a mobile experience perspective, images and templates for the UI of your app will likely coming from the AEM side (probably analytics too), while customer data is sent and received from hybris APIs. Hybris APIs are traditional REST/SOAP stuff.
If you need to learn something, you need to learn how AEM works and generates templates. Author -> Publisher -> Distributors.
I am wondering what is the role of CQ5 and Hybris here. In what ways it helps in managing a eCommerce application?
hybris is a framework to build ecommerce applications. CQ (AEM) is a CMS and DAM so it's not dedicated to ecommerce at all.
hybris also contains a CMS but CQ CMS is more advanced.
For me CQ is a good addition to hybris to manage pages that will be often contributed. The tool is more easy to use for someone that is not from the SI side. Also it offers more possibilities than hybris CMS.
Being an iOS developer, how far I should know about them?
It depends on what you're supposed to do.
I think CQ is not so hard to learn, at least for basic usage.
For hybris, without the intention of being mean, I would never hire an iOS developer. Indeed it's heavily based on Java EE technologies and Spring. So if you have no background in these techno you'll be quite useless...
Even Java developers I worked with experienced troubles when it comes to advanced development on the hybris platform.
If your role is only restricted to call WS exposed by hybris then you don't need to know anything about hybris. Ask the hybris development team to give you a documentation of the WS your supposed to call and that's it.
Related
I have an MVC application in production, hosted on Azure. Now I would like to develop Mobile app using Xamarin.Forms and Azure Mobile apps. The goal is to use the same database on both mobile and web. After reading available documentation online, I haven't found the way that would suffice my needs. I would like to know what is the fastest and best way to achieve that.
Is it enough to add necessary fields to existing entities that I would use in my mobile apps? Meaning adding fields like: Version, CreatedAt, UpdatedAt, Deleted and add another Id field of type string ex. MobileId (because current database uses autoincrement ids of type integer). Is this approach Ok, or should I do it some other way?
Any suggestion/advice would be much appreciated.
Azure Mobile apps is an accelerator and a way for devs not familiar with backend development to quickly create a backend for mobile apps. Since you already have a backend, you can simply add API methods in your MVC app that your mobile app will call. You will not benefit from some of the features that the SDK provides but you won't have to change your database structure.
You don't need to create a backend mobile app and in most cases you probably shouldn't. Is your app hosted in app services? If so there really wouldn't be any major differences between leveraging (and expanding as needed) the controller layer of your application. In most cases the datastore won't need to change to accommodate a mobile app vs a web app. Usually you want the datastore to change and evolve based on the features that you want your application to support as opposed to the plataforms that are consuming those features. It's usually a good idea to add an abstraction layer(s) to shield the datastore from platform specific requirements.
That being said there are a few Azure services that you should consider adding to make your life easier when developing Xamarin apps:
Notification Hub (provides an abstraction layer over the platform specific push notification services for ios and android).
App center (provides very useful telemetry data about crashes and errors that occur in your Xamarin clients).
App insights, it provides really good additional telemetry data with very powerful out-of-the-box visualization and querying capabilities for both web apps and mobile apps (I would configure app center to feed its telemetry data to App Insights).
If you provide me with more details about the application I would be happy to give you more detailed suggestions but the recommendations above serve as a good starting point for almost all the mobile application projects that I have encountered.
I'm developing with Azure Mobile Services (using SQL Azure) to provide a backend for both IOS and Android mobile apps and a PHP website.
My question is now that now custom apis have been introduced is it considered best practice to wrap everything up in custom api calls rather than e.g. using the CRUD table operation scripts directly from apps or websites?
Additionally for data access from a website should you lock down access to stored procedures and only exec via custom apis, to enforce a consistent approach no matter who the consumer is?
While I appreciate that custom apis and the table scripts are restful it still isn't clear how to architect a solution in the most efficient, reliable way that can enforce business rules in only place allowing each process only one entry point e.g. you have a stored procedure exec'd by an api called from the mobile apps. If the website calls that stored procedure directly without going via the api it could have unwanted side effects because other logic steps will have been missed.
I'm relatively new to Azure so forgive me if I have just missed something fundamental here. I've read many blogs and tutorials but they rapidly go out of date.
Many thanks
In my opinion the great feature of azure mobile services is the push notifications (to ios, android, wp). If you are not going to use that, there's no great advantage to use WAMS
(Windows Azure Mobile Services).
But it's a good choice using Windows Azure as backend since it's easy to scale up /down. In this case, you could create a Webapi and host in a Web Role. As it works with http, you can easily create Restful services and call them from your apps (ios / android).
We are trying to determine the best approach for adding a complex API layer to a modified version of nopCommerce. To back up a step, we're building out a custom site for a fashion/apparel manufacturer that has a lot of front-end application requirements and also needs to integrate with their cross platform apps (iOS, Android, Windows) which we're building with Xamarin. We've tentatively decided to start with nopCommerce as the base of our application to which we will add an API layer.
What we are unsure about is what is the best approach for implementing this in nopCommerce (or other similar .NET package)? The options we are considering are MVC vs WebAPI vs ServiceStack. We've been going thru many of the tutorials on PluralSight.com to get up to speed on app dev and API creation best practices, but there seem to be so many options, we're not sure where to start. We seem to be somewhat lost in a sea of implementation options for the API and how each is to be evaluated based on choice of the JS packages/frameworks used on the front-end for the web site and the tools chosen to create the apps.
If it matters, our basic requirements are:
Expand core of basic e-commerce package with some custom ERP style functionality
API layer that can work effectively with both a web front end (possibly as a SPA) and all cross platform apps built using Xamarin
Insure OAuth authentication across all interface types so we can just use social media logins consistently everywhere and can authenticate the user in any environment
Given this...
My question boils down to which of the three API methods (MVC vs WebAPI vs ServiceStack) is best for this?
In my humble opinion you should go with service stack, it´s easier to implement and a lot more flexible than web api, you can add/remove plugins for different functionalities you get a lot of infrastructure code OOB such as mechanisms to handle cache, loggers and other not just related to infrastructure such as validators and IOC container, etc.
you'll get a single mechanism for authentication including custom auth, oauth, oauth2, etc which works for linked in, facebook and google +, in that situation you´ll find yourself reusing a lot of code in across all your apps.
One other thing that I like about SS is that practically is just you and your IOC, nothig else, everything is quite simple to understand and to implement (there could be more than one hidden option or configuration you may miss in the documentation but you get a lot of support from the community in google groups or stackoverflow)
its easier to test (Unit testing) you already have abstractions for httprequest and httpresponse and a lot of more, you won´t find yourself doing wrappers for all the legacy web impl that are shipped with mvc.
SS is better than mvc web api in terms of performance, it got one of the fastest json serializers out there for .net
I´m working on a SPA app for the time beign and I have no regrets about my desition to get into the SS framework.
just my 2 cents.
I would say Web API is best option for the Services Layer
- http://www.asp.net/vnext/overview/aspnet-web-api
There are many advantages
- Web API has been in release cycle as separate component with latest features
- Security
- Versioning
- Attribute based routing
- OData integration
I am very new to IOS development.I wonder which language/framework everyone is using to create RESTFUL web services for high traffic, scalable IOS app backend.
The solution requires:
1. Secure Login
2. Restful web services (JSON)
3. High traffic
4. File upload/download
5. Quick search result from large volume database
I am from .NET and MSSQL background. I heard people are using PHP, Java, Python, RoR with IOS webservice development. I understand every language can have pros and cons, just want to know what is prefered in today's trend.
And for database, is NoSQL database a prefered choice than RDBMS for scalable large volume databse? I am checking MongoDB.
Apologies if I am asking wrong questions. I am investigating the technologies for this new project, and any input will be greatly appreciated!
Thanks
I have worked in three major projects that all of them have desktop clients, web clients, and mobile clients (Android, iOS). The 3 have completed different server side approach, and all of them make me and the users happy:
Project 1:
Server: Delphi + RemObjects
Clients: Delphi desktop apps, PHP Web apps, Java applets, Android apps, iOS apps
Why Delphi? Because the existent project was already a Delphi multi-tier app, the development team have domain of Delphi platform, ans was easy with RemObjects (or even with the standard DataSnap) to return JSON, SOAP or XML-RPC to be invoked by the clients;
Project 2:
Server: PHP
Clients: ExtJS Web apps, Android apps, iOS apps
Why PHP? The development team was experienced with PHP, the projects was originally a PHP web app with some classes well defined and not coupled with the UI. Some new classes in the server that reused the existing code base, just converting to/from JSON were enough to allow the clients to talk to the server, with minimum effort.
Project 3 (initial development):
Server: C# ASP.NET
Clients: ASP.NET apps, Android apps, iOS apps
Why C#? Again: the development team was experienced with C# and ASP.NET, the projects was originally an ASP.NET app. We are refactoring some app logic into web services that will be consumed for both the ASP.NET app and the clients.
As you see, there is no need to make the team learn something completely new on the server side.
I'd suggest you to keep your development in .NET with MSSQL, taking advantage of your current skills.
If the application traffic grows you can move the server app to an IaaS server (like Amazon AWS EC2) that supports SQLServer, or even better to a PaaS server, which in this case Windows Azure will probably be your best friend.
These are all loaded questions that can't be answered without more information about what you're making, etc. I use a combination of Ruby with Sinatra and DataMapper (and SQLite/PostgreSQL) for most of my projects, but that's my personal preference and probably won't be of much help to you.
Rather than choosing a technology stack based on trends, why don't you just pick something with a good user base for help and go from there?
I have a few questions concerning how to create a VoiceXML application.
I found some nice tutorials, but there are still some questions:
-what's a good development environment? I wanted to use VS08, there should be under C#, a project called "speech", but it doesn't appear, do I have to install the speech server local too in order to use this? (I would prefer some kind of visual workflow)
-what's the ending? is it .xml, .aspx, or .speax? I couldn't get that.
-how do I run the voicexml? it's at the speech server as an application, any further steps?
These questions are all over the map on the basics, but I'll try to provide some pointers:
what's a good development enviroment?
You will likely be building a web style application. So a VS08 ASP application is a reasonable starting point.
do i have to install the speech server local too in order to use this?
Yes. There are a variety of platforms that support VoiceXML. Nearly all are designed specifically for telephone calls (VoiceXML's main purpose). There are a few free implementations, but most are commercial. I believe the Opera web browser has some VoiceXML functionality. I've seen settings for it in their configuration, but no direct experience.
what's the ending? is it .xml, .aspx, or .speax ? i couldn't get that.
Endings usually aren't relevant, except maybe to tools. I don't believe VisualStudio provides any direct support for VoiceXML. Some browsers do care what mimetypes are provided.
how do i run the voicexml? it's at the speech server as an application, any furhter steps?
Does this mean you are looking at the OCS/Lync product line ? I believe their IVR in that suite does support VoiceXML as well as a few other APIs. The product should contain basic setup and configuration information. More information on Lync:
Microsoft Lync site
Wikipedia
One of the main goals of VoiceXML was to decouple the rendering of the voice application (on a speech server) from the voice application itself. This allows you to serve VoiceXML pages from any web server, anywhere, using any technology stack you want.
If you just want to learn VoiceXML in general, developer sites like Voxeo's Evolution allow you to render your voice applications on their voice hosting infrastructure. You configure your developer account to point to an initial VoiceXML page served from your external web server. In return, you get a phone number to call. When you call it, the hosting infrastructure fetches your initial VoiceXML page from your web server.
(I don't know offhand if Microsoft Lync hosting services are available yet.)