I've developed an Ionic application which works as an online shop.
The app opens views like this (in a flow)
Start -> Articles -> Cart -> Checkout (-> Credit card payment) -> Order confirmation
When the user presses the back button in the order confirmation view, Ionic goes back to the Checkout (or credit card payment) view. This makes sense for Ionic, but for the user it's weird to go back to checkout when just ordered. How can I close the cart/checkout/cc-payment view that is open underneath the confirmation, so that when pressing the back-button, the user is taken to Articles?
You can use the $ionicHistory service.
With this you can call something like $ionicHistory.goBack(-2) in your controller to take you back 2 views instead of the default one view.
Related
What is the proper way to update the home tab on the Slack mobile app after a modal sends a view_submission event? FWIW, the home tab updates on the web UI but on mobile it does not and the person has to click away from the home tab and then back on it to update it.
Here is the flow I'm using:
Modal is opened and person submits form from modal.
Modal sends view_submission to my app.
My app sends {'response_action': 'clear'}.
My app posts home tab layout to views.publish.
I'm expecting the home tab layout to update. On the web UI it does update, but on the Slack mobile app it does not update. On the mobile app you have to tap to another section (eg Messages tab or another conversation) and then back to the home tab for the update to happen.
A work around (or maybe the correct way to do it depending on how you interpret Slack's documentation) is to return the acknowledgement response when you get the view_submission request from slack BEFORE you make a post request to view.publish.
Generally speaking, the simplest way to process the flow above is to take the view_submission data, figure out what updates need to be made, post the update via views.publish, and then return the acknowledgement response {'response_action': 'clear'} all in a single synchronous process. This works as expected on web, but not on mobile. Instead, however, if you break it into two steps and use a job queue or other asynchronous system to offload the processing of the view_submission data and posting the update via views.publish and immediately return the acknowledgement response then it works as expected on web and mobile. For performance reasons you'll just want to make sure that the view_submission data gets processed immediately after returning the acknowledgement response.
I have a website with 200 items listed on a separate landing pages. I want to provide BuyNow button for all these 200 items. I do not want to create a individual "BuyNow" button. Instead, when user clicks on any of these BuyNow button it should only pass item name & item value & complete the transaction. How to do it?
Since website will grow to more than 1000 items, it will not be feasible to create separate buy now button for each item via paypal account. I need to create only One Single "BuyNow" button which I can copy on each page and depending upon item listed on the page, it should show item name & item value so that user can proceed for checkout. Its similar like Fiverr. Appreciate anyhelp in this regard.
This is possible but not practical. Buy Now button is intend for checking out only ONE individual item.
If your website will grow until 1000 items, it is recommended that you look at other kind of solutions, which involves programming knowledge. We have vast amount of options, one of the popular integration is using our PayPal Classic API.
To get started and explore, check out https://developer.paypal.com/
Following the instructions in their documentation, I've successfully implemented a PayPal Advanced solution within an iFrame. The process works fine using a credit card. However, there are also two buttons that show up in the form for "Checkout with PayPal" and "Checkout with BillMeLater..."
When the user clicks either of these buttons, the window breaks out of the iframe and the session has expired.
Can this top of the form be hidden, or at the very least, be made to open within the iframe and keep the session, as it should?
Thanks for any help and suggestions.
Which layout option are you using? A, B, or C? It sounds like maybe you have a conflict there..??
Chapter 3 of the PayFlow documentation covers this in depth.
I have a design decision to make for an online ordering app. I believe this question is for a more advanced iOS/mobile e-commerce developer but I am welcoming everyone to help out.
I'm thinking to install a CMS like WordPress and add a shopping cart plugging. If i need to have mobile specific pages, then I shall create those too, also If I need to make certain PHP calls, then I need to customize the API for it too. The payment page obviously will be done using the e-commerce plugin as well. This all looks like 1-3 months of work, but i would LOVE to start on the right path. So any feedback or direction would be much appreciated.
Right now, I have to come to make a decision on how my users are going to view the products and the shopping cart from their iPhone. I'm thinking of developing an iPhone App to allow them to order online. Obviously, the app will not just be a wrapper for the page but will have other useful features in addition to the product and cart views.
So here is the question:
The app I'm thinking of is a UITabBar app composed of two views "Product" and "Shopping Cart".
Option 1 - Native controls with individual HTTP posts to add products to the car, and GET to read from the cart.
The Product view implements a native UITableView, each item opens up a Custom UITableViewCell where the user can push a native button to "Add" to the cart. When the "Add" button is pushed, an HTTP POST is made with the product code and quantity and somehow it is written to the server's cart under one session. I still need to figure out how to obtain a session key for the cart (any ideas here would be MUCH appreciated).
The Cart view is also implemented completely with native UI's, I haven't figured out what I need yet, but it will retrieve the Cart's current items for the users session and display it. Obviously, the user can modify items, add comments, change quantity, etc.. This sounds like a lot of headache if i need to make HTTP Posts every time something changes in the Cart to sync up with the shopping cart on the server, but never the less, the CART is completely viewed in native UIs.
Options 2 - Product and Cart are we pages that can be viewed and manipulated using UIWebViews
The Product view is only a UIWebView that opens up a pre-made product page on the web, the page obviously has to be mobile friendly so it can look decent on the phone. When the user click on the item, it will open up the detailed product web page and the user will have a web button to click, in order to add to the cart. Of course, I can intercept these clicks using the standard UIWebView callbacks and examine the request URL to figure out which product was clicked.
The cart view in the other tab (UIWebView as well), once clicked, will make a request to the server's cart page to display the cart under the same session. Of course, I need to figure out how to have the two UIWebViews to share the same sessions so I can get the correct cart. I still haven't dove in the code.
Options 3 - Keep the product view and shopping cart completely on the local phone and only push out the final "order" to the server to follow through the payment pages
At the app start, I download the product catalog, reset the local shopping cart and simulate the cart logic in the app. Once the user is ready to checkout, i make a final call to the payment page with all the products and quantity requested. The user will then follow the page with the payments.
Since the user can also use the web page to make orders, I would need to duplicate all the logic into the app and handle the shopping cart completely from within the app. The final "check out" also need to send the detailed product code, with "comments" to the payment page. did I mention there is a user registration process as well?
Which options would be best suited in terms of usability, efficiency and user experience?
How can I sync up the two views if i would go with option 2?
Are there any shopping cart solutions anyone has experience with?
You can use 3rd party libraries,
in .h file just create object for BBBadgeBarButtonItem like this
BBBadgeBarButtonItem *barButton;
after that in your .m file set your custom button to that barButton,
barButton = [[BBBadgeBarButtonItem alloc] initWithCustomUIButton:yourBtnOutlet];
barButton.badgeValue = #"0";
barButton.badgeOriginX = 13;
barButton.badgeOriginY = -9;
after that after your response we can use this line of code, it will increment the count value
barButton.badgeValue = [NSString stringWithFormat:#"%d", [barButton.badgeValue intValue] + 1];
I'm working on a custom e-commerce system for a client and ran into a fork in the road. The checkout system I'm using is very flexible and is meant to be integrated into an existing Web site. So essentially, I have all my products on a page. Each product has a "Buy Now" button associated with it. When clicking on that button, a modal window opens, showing a cart-like screen with the item they chose being added. From here, they can either close the modal window and "buy" another product or checkout. Here is where the fork comes in:
Option A: They are now redirected to the merchants site for the actual checkout. I can make that page look anyway I want, but it's independent from the client's real site. So if something on the real site changes, I have to update my files on the merchants site manually so there won't be any confusions e.a. a new menu item is added in the header.
Pro: They checkout on a page that's branded as the client and it takes up the full page. It might provide a better sense of security as apposed to option B.
Con: May involve some manual maintenance to keep the appearance of the site consistent.
Option B: When the modal window displays and they click on checkout, a new window/pop-up opens up. It shows them everything they need to checkout... name, address, billing info, etc. It would still be branded as the client's checkout system, but you wouldn't see the entire site (header/footer) in that pop-up window.
Pro: No maintenance involved and they'll always see the site in the background and know where they are at. On completion of checkout, they can close the window and are right back where they left of.
Con: It might defer some people from checking out, because you can't really tell where you're entering your credit card info... although it would be branded accordingly. They may also have a pop-up blocker that could prevent the window from opening in the first place.
Does anyone have any experience with this? Are people less likely to checkout from a pop-up window vs. a full page checkout system?
Any feedback much appreciated.
-Ryan
The answer is to brand the Web site and not use a pop-up, even if it requires some manual updating of the headers and footers. The reason being, that from the user's perspective, it can be hard to tell whether this is a pop-up from that site you just clicked "Buy" on or whether this is an ad from that site or another open tab. Furthermore, if you look at what everyone else is doing, you don't ever check out in a pop-up window. Lastly, the moment something pop-up asking for my credit card, I tend to close it, so knowing how I react to those, I answered my own question.
Case closed.
-Ryan