Adding App

addingapp

Strengthening OAuth2 for Mobile

You’ve got your React components. You figured out how to use Redux to feed them data. You make a component that creates/updates/deletes an item in your API, and put it in a page displaying the items from your API. How do you get the whole page to reload to show the updated data every time a user makes a change? Redux state and the Dependency Array. useEffect() It is possible to use only React to pass the data from our counter to the parent element to get almost the same counter effect in my example, but using Redux state and the React Dependency Array is easier in some ways, and applicable to many more situations. useEffect() This article assumes basic familiarity with APIs, React, Redux, and Node. I started this app with create-react-app and am using functional components and hooks. You can find all the code in . I’m working with React (v17.0.1), Redux (v4.0.5), (v7.2.2), and (v2.3.0). For this example, I used to get random Shiba Inu pictures to display. this repository react-redux redux-thunk Dog API After testing the API endpoints (in this case in the browser with ), I started by setting up my action types and action creators for the Dog API GET request. I’m able to create async actions thanks to redux-thunk. For this small example, I’ve left my fetch requests inside the action creators. JSONView The following are the results of the action creator, with the loading action, which will be important later. > shibaActions.js
function shibesRequested() { return { type: shibaConstants.SHIBES_REQUESTED } }
function success(result) { return { type: shibaConstants.SHIBES_FETCHED, payload: result } }
function failure(error) { return { type: shibaConstants.SHIBE_FETCH_FAIL, payload: error } } Next the reducer: > shibaReducer.js
const reducer = (state = initialState, action) => {
    switch(action.type) {
        case shibaConstants.SHIBES_REQUESTED:
            return {
                ...state,
                shibasLoading: true,
                shibasFetched: false
            }
        case shibaConstants.SHIBES_FETCHED:
            return {
                ...state,
                shibasLoading: false,
                shibasFetched: true,
                shibas: action.payload
            }
        case shibaConstants.SHIBE_FETCH_FAIL:
            return {
                ...state,
                shibasLoading: false,
                shibasFetched: false
            }
        default:
            return state
    }
} Finally, I initialize the store. The first item in the composeEnhancers enables , and this setup allows the use of both dev tools and middleware (in this case, redux-thunk). Redux Dev Tools > index.js
import { compose, createStore, applyMiddleware } from 'redux';
import { Provider } from 'react-redux';
import thunk from 'redux-thunk';
import reducer from './store/shibaReducer';
const rootReducer = reducer;
const composeEnhancers = window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ || compose;
const store = createStore(rootReducer, composeEnhancers(applyMiddleware(thunk)));
ReactDOM.render(
  <React.StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </React.StrictMode>,
  document.getElementById('root')
); On to our components! I set up App.js to display Shiba pictures based on a number in local state. Were this a real app, I would take the time to create a unique key and alt text for each picture. > App.js
import { connect } from 'react-redux';
import { shibaActions } from './store/shibaActions';
import Counter from './components/Counter';
function App(props) {
  const [number, setNumber] = useState(1);
useEffect(() => {
    props.fetchShibes(number)
  }, []);
if (!props.shibes || !props.shibes[0]) {
    return (<h1 className="heading">Loading!</h1>)
  } else {

    let shibaImages = props.shibes.map(shiba => {
      return (
        <img className="image" src={shiba} alt="shiba" key={shiba}>
        </img>
      );
    })

    return (
      <div className="App">
        {shibaImages}
        <Counter />
      </div>
    );
  }
}
const mapStateToProps = (state) => {
  return {
    shibes: state.shibas
  }
}
const mapDispatchToProps = (dispatch) => {
  return {
    fetchShibes: (num) => dispatch(shibaActions.fetchShibes(num))
  }
}
export default connect(mapStateToProps, mapDispatchToProps)(App); An empty Dependency Array (the brackets after the function) means the page won’t re-render indefinitely, nor will a re-render be triggered by updates to the component’s dependencies. useEffect() Note: and the React team advise against empty Dependency Arrays because they’ll hide bugs. Denny Scott Now that my shibes are being displayed, I’ll start the counter component. Because this API doesn’t have POST, UPDATE, or DELETE endpoints, the counter will change the value of passed to the GET request url within the action creator. num let url = `https://dog.ceo/api/breed/shiba/images/random/${num}`; First I update my action types, action creators, and reducer. In this small example, I’m using a single file for each of these, but I would typically have multiple reducers and use the hook. combineReducers() > shibaActions.js
function addOne(num) {
      return dispatch => {
        let number = num + 1;
        dispatch(add(number))
      }
  function add(number)  { return { type: shibaConstants.ADD_ONE,  
  payload: number } }
}
function subOne(num) {
      return dispatch => {
          let number = num - 1;
          dispatch(sub(number))
      }
  function sub(number) { return { type: shibaConstants.SUB_ONE, 
  payload: number } }     
}
> shibaReducer.js
case shibaConstants.ADD_ONE:
   return {
       ...state,
       counter: action.payload
   }
case shibaConstants.SUB_ONE:
   return {
       ...state,
       counter: action.payload
   } I also add the counter to the initial state, so that there is always 1 shibe. > shibaReducer.js
const initialState = {shibasLoading: false, shibasFetched: false, counter: 1}; Now for the counter component itself — pretty straightforward. > Counter.js
import React from 'react';
import { connect } from 'react-redux';
import { shibaActions } from '../store/shibaActions';
function Counter(props) {
    const handleOnAdd = () => {
        props.addOne(props.counter)
    }
const handleOnSub = () => {
        props.subOne(props.counter)
    }
return (
        <div className="container-counter">
            <h1 className="heading">Counter!</h1>
            <button onClick={handleOnAdd}>+</button>
            <p>{props.counter}</p>
            <button onClick={handleOnSub}>-</button>
        </div>
    )
}
const mapStateToProps = (state) => {
    return {
        counter: state.counter
    }
}
const mapDispatchToProps = (dispatch) => {
    return {
        addOne: (num) => dispatch(shibaActions.addOne(num)),
        subOne: (num) => dispatch(shibaActions.subOne(num))
    }
}
export default connect(mapStateToProps, mapDispatchToProps)(Counter); Next, to make our page reload every time the button clicks change the counter, we have to go back to App.js. We’ll use to access the counter within the page component, and pass it instead of the local state when we dispatch . mapStateToProps() number fetchShibes() > App.js
// const [number, setNumber] = useState(1);
useEffect(() => {
    props.fetchShibes(props.counter)
  }, [props.counter]); As you can see above, the only thing we have to do to get the page to reload with the button changes is put the counter state in the dependency brackets (the React team advises assigning the state to variables instead of using within the Dependency Array). Add just a smidge of styling, and we have a basic, little Shiba Counter. useEffect() props.state Getting the page to reload based on an async action is only slightly more difficult — you’d use the loading state like above. If you only use the end result state, like , then the page will only reload based on the first successful request. So if you have a user adding multiple things to your API, it will only show the first. shibasLoading shibasFetched This concept also lends to creating error messages within your app. After adding the and state objects to , I updated my App.js file. shibasFetched shibasLoading mapStateToProps() > App.js
if (!props.shibes || !props.shibes[0]) {
    return (
      <div>
        {(props.shibasLoading || !props.shibasFetched) && <h1  
        className="heading">Loading!</h1>}
        {!props.shibasLoading && !props.shibasFetched && 
        <h1>Something went wrong - shibas not loaded.</h1>}
      </div>
    )
  } else {

    let shibaImages = props.shibes.map(shiba => {
      return (
        <img className="image" src={shiba} alt="shiba" key={shiba}>
        </img>
      );
    })

    return (
      <div className="App">
        {!props.shibasLoading && !props.shibasFetched && 
        <h2>Something went wrong - shibas not loaded.</h2>}
        <Counter />
        {shibaImages}
      </div>
    );
  } Using JSX conditional logic and our Redux state, we can display different error messages based on the state of our async requests. Conclusion After struggling to figure it out myself, I strove to create a straightforward example of how to use the hook to reload components based on changes other components are making. useEffect() There are many ways to use this across an app, and the basic concept itself allows you to do fun things like custom error messages using JSX conditional logic. If this helped you when you got stuck or left you with a question, leave me a comment! Also Published here

How to Immediately Update Components Based on User Interaction with React/Redux

App debugging is an essential part of the app development lifecycle. Bugs can be insidious, and we need to find them as fast as possible to get more time for fixing. Yes, of course, it would be great to write code without any issues that work just perfect, but we are people, and it’s a normal thing to make mistakes. In this article, you will read about some useful & fun tools that I prefer to use in my day to day iOS app debugging at . We will touch a few themes like: Uptech Signpost Charles Proxy Chisel Breakpoints You might already be familiar with some of them, but I hope you will find out something helpful and optimize your workflow using tips and tricks below. Have a nice reading 🚀. Signpost On WWDC 2018, Apple introduced a new method , for . That is available from iOS 12. So, let’s check Apple’s documentation for it: so_signpost os_log framework Marks a point of interest in your code as a time interval or as an event for debugging performance in Instruments. It looks like signpost is a custom marker, that can make our work with Xcode Instruments a little bit easier. For example, we need to check what happens in viewDidLoad method on some specific screen. We can do it with just a few steps: 1. Initialize object by passing a few parameters. Bundle identifier to and to . The last one will help us to display our logs in Point of Interest instrument. OSLog subsystem: .pointOfInterest category: 2. Calling for the first time with , passing our log object and set the name of our measurement. os_signpost OSSignpostType.begin 3. Balance call of with os_signpost OSSignpostType.end That’s all, let’s profile it! As a result, Point of Interest will display a measurement event on the timeline, and we can easily find a place that we were interested in. Charles Proxy is an excellent app for network debugging. But it can do more than just displaying requests or responses. Charles Sometimes you need to get some specific data from your API to reproduce a specific behavior. You can do this without any changes in your codebase by mocking the response in Charles. First of all, let’s make it work with iOS simulator. We need to install a root certificate. -> Help SSL Proxying -> Install Charles Root Certificate in iOS Simulators. *Make sure you close a simulator before doing it, otherwise it will not work. So, we have a simple app that sending a request to the server and display response in a label: To mock a response we need to do a few steps: Find a request that you are interested in and open a context menu (right-click), choose . (Save it as a .json file)In the same context menu, you need to select . You will see an window.Fill a field with your path and press OK. Save a response Map Locale Edit Mapping Local path Nice, our response mocked! Now we can modify a JSON file. On the next request, you will get an expected response. Also, we can do the same with breakpoints that might also be useful. 1. Select a request and open a context menu (right-click), choose . Breakpoint 2. After making a request in the app, the breakpoint will be triggered, and Charlies will show a window where you can modify headers, body, etc. Press to continue. Execute 3. When you get a response, a window will be updated. Now you can modify a response body, code, and headers. Press Execute to pass a response to the app. Chisel Some great engineers from Facebook created a repo named . It is a collection of commands that can help you improve your debugging session. You can find an installation guide . Chisel has a big list of available commands. I will show a few of them below. Chisel LLDB here 1. taplog will set a breakpoint to and some conditions to filter all touch events. taplog -[UIApplication sendEvent:] After any touch event, the breakpoint will be triggered and print a debug description about the object to the console. 2. vs I didn’t find this command useful to myself, but it actually can take you on a short interactive trip through your views hierarchy with some visualization. The interface looks like this: Small example: 3. pviews It’s a simple command that prints the view hierarchy. 4. flicker, mask & border I put these 3 commands in one part cause they are for the pretty same purpose. They can help you find UI elements faster. will show and hide element to make some flickers effect. flicker will add a red layer to view. mask and will add borders around. vs border 5. pjson It’s a nice command that formats a default printing description of NSDictionary or NSArray to a regular JSON. From this 👇🏻 To this 👇🏻 Amazing! What can be better? Breakpoints Breakpoints in LLDB are powerful and easy to use with Xcode UI. In this part, I will talk about some exciting features that can be useful. 1. Conditions Probably you already know about it but anyway let’s take a short look. To set a condition, you need to right-click on the breakpoint and choose On the image above, it will be triggered when the will be more than 2. Edit Breakpoint. counter 2. Debugger command Breakpoints can execute a LLDB command through actions. Here a small example: will skip the current line. In this case, if a condition is passed, we will go directly to function without increasing the . thread jump -by 1 updateLabel counter 3. Apple scripts Let’s imagine for a second that you need to hear something when a breakpoint was triggered? You actually can do it, since breakpoint also supports an . Apple Script Okay, to be serious AppleScript is a powerful and simple language. You can do a lot of stuff through it, like making a screenshot, send notifications, etc. 4. Sound Breakpoints also support a default system sounds; theoretically, you can play a custom one through AppleScript but it’s more for fun 😄. Usage of sounds can be helpful if you are doing a live debugging and need to make sure if some code calls ones. 5. Log message This one can be useful in case you need to log some expression without adding a function and rebuilding the project. Also, we can make MacOS speak it (like we did with AppleScript). print Although very useful, these tips & tricks for iOS app debugging are not hard to learn. Start using them as soon as possible and enjoy less time wasted on debugging and flawless apps. Thank you for your time. Don’t forget to put some claps and leave comments if you enjoyed (or not) this article. Peace. Love. Uptech. 😊 Useful links: WWDC 2019: Getting Started with Instruments WWDC 2018: Measuring Performance Using Logging Raywenderlich: Charles Proxy Tutorial for iOS WWDC 2018: Advanced Debugging with Xcode and LLDB WWDC 2016: Debugging Tips and Tricks Application sarvar Uptech blog

Tips And Tricks For iOS Application Debugging

App development has been one of the most lucrative decisions that multiple companies have made in the past. Even large as well as small newspapers outlets are starting to develop personal applications in order to suit the needs of a more modern customer base. The main attraction of having an application is that it’s much cheaper to maintain in the long run. For example, in the past, most of the funds for a newspaper company was going to printing, delivering and the general staff in the company. Now though, all of the costs are directed to staff as delivering and raw materials are not required anymore. However, this doesn’t necessarily mean that every company or person making an application is going to see it blossom into a lucrative idea. Many fail to comprehend that in order for the app to be useful, so should the product itself. But we’re not here to discuss the usefulness of products, we’re here to discuss how you should structure your future applications. In this article, I will explain how adding a gaming aspect to your application will help it stand out from the rest of the competition and make it a lot more enjoyable for everybody to use. But first, let’s start with some explanations and data about this whole concept. Is there evidence that gamification is good? Although we can simply take a look at the metrics for gamified apps compared to non-gamified ones, there is still a lot more to understand before we decide to include the feature. Things like relativity, customer base and etc are essential parts of the application that need to be considered. Most developers, when talking about the gamification of their mobile applications, talk about the engagement and the time spent by the users on the platform itself. This is only useful when the application is dependant on its users viewing advertisements inside the platform. But, when the application itself is paid, then there is very little use for the time spent. You don’t really expect to see ads when you pay for an ad now do you? As far as go about gamification about mobile applications, the internet is pretty hard to scrounge. However, studies about gamification itself are abundant. official studies For example, one study combined the efforts of several other studies and tracked the data of around 10,000 people who were basing their experience on gamified activities. The results were shocking as more than 90% of people who participated in gamified events made a lot more progress and stuck to the habit than those who didn’t. Now, in order to translate this into mobile applications, we need to visualize what it actually looks like. Examples on the market Naturally, I’m not saying that you should copy every successful application that has implemented this feature. All you have to do is take a look and be inspired. It should be enough to put you on a road of creating your own original way of turning your app into a fun utility for your users. Loyalty programs One of the most popular gamification examples that we can see in mobile applications is the loyalty program. Sure, it may not seem so on most platforms, but it’s actually a perfect example of adding gamification. You see, it should not be as obvious on the app. It should only support the main use of the app rather than overshadow it. Those added points that you get when logging into a specific app are a much smaller representation of gamification though, we mean something completely different. For example, let’s take a platform which is already about games. The iGaming industry. All they do when developing apps is include as many games in it as possible because that’s the sole purpose of their business. However, some have managed to gamify even the games through loyalty programs. They usually look like this: Log in = “special token” "Special token" = "special game" The longer you play the "special game", the more real tokens you get It’s basically like developing a specific platform for free so that players then are transitioned into something that is monetized. In order to trace and control this flow, the iGaming platforms . Through this, they track the transparency and fair gaming policies of their platforms. If you’re more interested in how this actually works, you can check how tackles the issue. It’s a blockchain platform designed especially for iGaming platforms which helps it keep fair and simple. use the blockchain technology provably explained Perform tasks = coins to play Another example of gamification is rewarding the users for performing tasks or just using the application on its own. This type of feature only works for applications that on them. Things such as tracking your habits, your goals, training, calories and etc. It’s pretty much something that rewards you for completing your daily goal whatever it could be. have some kind of tracking device Naturally, the game itself is developed so that it’s supporting the main idea of the application rather than becoming the main attraction. One example I can think of right now is Habitica, which is an application developed to help you track your habits. People can input pretty much anything, such as daily habits of meditating, staying under their daily caloric needs if they’re trying to lose weight and etc. The app helps you rank what habits are more important and therefore reward you with different types of goodies. Naturally, it’s about self-discipline to know when you broke a habit and indicate so in the application. The gamification part starts when you actually complete those goals. The game allows you to create an avatar or a character which you can level up, choose classes for like in World of Warcraft and gear up with the experience and points you get from completing your tasks. It turns your habits into a role-playing game which helps you to stay motivated as that next level or an amazing piece of gear is so close. And if you’re using the app with friends, it creates a competitive environment, thus giving you a lot more motivation to stick to your habits. This is in no way promotion for Habitica, but rather a display of how you can do gamification correctly, while not harming the main idea of your project. Interactive gaming Interactive gamification is adding a game to an already physically heavy application. For example, imagine any step counting application and you will understand what I’m trying to say. Even Samsung’s health app tracks the steps of the user but doesn’t really do anything with it. There are many apps out there that reward users with gifts and sometimes even compensation for their performance. Those who use walking apps regularly have said multiple times that being rewarded for walking is giving them a lot more motivation to skip the metro and actually walk home when there’s sufficient weather. All in all, gamification is nothing but a motivator for people to use the app and utilize its primary function rather than keep the users online. The psychology of gamification As already mentioned, the in the application is to let the users know that they are being rewarded for their efforts. psychology of gamification As long as the game does not come across as the main aspect of the app, they will be more and more drawn to the platform. Naturally, you as a developer will have to focus on integrating this feature in a perfect way possible depending on the niche that you’re trying to target. But remember, that there are pretty much no exceptions in this case. Everything can be gamified, even games themselves.

How Turning your App into a Game Increases its Popularity

After selling his previous company for over $900 million, David Karandish is now building Jane.ai, an AI-native knowledge management platform to make company intelligence accessible in the simplest way possible What’s your background, and what are you working on? I’m David Karandish — CEO of , an enterprise artificial intelligence software company. We’re building an AI-native knowledge management platform to make all company intelligence accessible in the simplest possible way — via natural language. Before founding Jane.ai, I was the CEO of Answers Corporation. My business partner Chris Sims and I started the parent company of Answers in 2006 and sold the company to a private equity firm in 2014 for north of $900 million. Jane.ai I received a bachelor’s degree in computer science and a second major in entrepreneurship from Washington University in St. Louis. I live in STL with my wife and our 3 daughters, 1 son, and zero cats. What does your company do, and who uses it? Jane makes company information accessible by integrating with apps, mining intel from docs, and learning tacit knowledge — giving team members instant access to all the information they need to excel in their work. Jane is unique because it is used by an entire team to gain near instant access to the information they need. We have customers in verticals such as financial services and education, and departments like HR and IT. In the last two years, we’ve had hundreds of thousands of questions go through our system. We started with 6 people on January 1, 2017, and now have around 60 team members — and we’re still hiring! What motivated you to get started with your company? I came up with the idea for Jane because I was tired of how many emails I had to send or people I had to ask to get even a simple piece of information like, “When did we last adjust a team member’s compensation?” I was frustrated that Netflix knew more about my preferences than the software we used at work. I knew there had to be a better way. I saw the rise of platforms like Siri and Alexa in the consumer space and suspected that a similar concept could succeed in the workplace. When we started the company, our goal was to sign our first paying client within 6 months — or pull the plug and move onto the next idea. We ended up signing our first client at month 5, day 30. I’m of the belief that if you can convince people to engage in the unnatural act of opening up their wallet and paying you for your service, then that’s a good gauge for validation. After a successful exit from Answers.com, I had a never-ending list of ideas I wanted to pursue. Starting Jane.ai was the one idea that I knew I’d always regret if I didn’t try. Before launching Jane, I had worked in the tech sector for over 17 years, in SaaS and online advertising and got to dust off my CS degree. If Jane.ai hadn’t succeeded, my next idea was a fast-casual Indian food restaurant. Maybe for another day… What went into building the initial product? Initially, we built a prototype. The first version of Jane existed as a chatbot within Slack. You ask Jane a question, she comes back to you with an answer. We then started adding app integrations — weather, email, maps — the most commonly used services. From there, we started grouping the sources of all company intelligence into three buckets: apps, documents and people. For apps, we built more integrations, an internal API and are now developing an external dev platform for clients to build apps on top of Jane. With documents, we’ve developed some tech to read the contents of a document and add it to our knowledge base. Our knowledge base has been our breakout hit — storing the information in an organization that doesn’t have a home in either apps or documents. All of this required us putting together a stellar development team. Specifically, a team that can balance both speed and scale. We bootstrapped the company to get started. We subsequently raised a Series A round and are wrapping up our Series B. The company is about 2 ½ years old today. How have you attracted users and grown your company? To date, we’ve taken a syncretic approach to customer acquisition. Initially, we started out on the “friends and family” plan, meeting with a lot of companies through the YPO (Young Presidents Organization) Network. We then began building out a geographically distributed sales team and a centralized marketing team. Within marketing, we split between “analog” or traditional marketing (events, trade shows, PR, etc.) and “digital” (SEO, LinkedIn, Email, etc.). We are now adding a third angle with a newly formed strategic partnerships group within the company. What’s fascinating is the power of these channels working together. Someone may have seen a LinkedIn video, read an email and attended a tradeshow before getting the full demo experience. These channels continue to build off of one another and multiply their effectiveness. What’s your business model, and how have you grown your revenue? Our business model is Software as a Service with the majority of our clients on multi-year contracts. It sounds intuitive, but our revenue growth is directly tied to our ability to get qualified leads and demonstrate our product in action. My advice to aspiring entrepreneurs on this point would be to focus on your target customer and what the characteristics of that customer are. What are your goals for the future? Our mission is to help teams do their best work. We believe we can accomplish our mission by being the AI-native knowledge management platform for enterprise companies. The way we get there is by building the best product for our customers that meets their needs — being customer-centric is key to how we are building the company. What are the biggest challenges you’ve faced and obstacles you’ve overcome? If you had to start over, what would you do differently? If I had a Delorean and could go back in time, I would tell my 2017 self that enterprise companies haven’t adopted chat platforms (e.g., Slack, Skype) at the same rate that small and midmarket companies have. Therefore, in the enterprise, it’s important to give our users multiple modalities of accessing their knowledge. yet Have you found anything particularly helpful or advantageous? At my previous job, my inbox was bursting at the seams and I would be getting pinged every couple of minutes, making it impossible to focus during work or relax outside of work. So, I started practicing an “email Sabbath.” Once a week, usually from Saturday afternoon to Sunday afternoon, I don’t check my email (or Slack). I give myself 24 hours where I can unplug and be refreshed. It’s a wonderful time to connect with family, read a book, take a nap, get some fresh air — whatever, as long as it’s rejuvenating and will get me centered for the week ahead. What’s your advice for entrepreneurs who are just starting out? Focus relentlessly on your customer acquisition channels. Bring strategic marketing into your org as soon as you can. Where can we go to learn more? You can find us at . Jane.ai Please feel free to ask questions about Jane.ai or my journey as an entrepreneur in the comment section below! This interview is brought to you by , a tool to schedule and automatically repeat your posts on Facebook, Instagram, Twitter, Pinterest, LinkedIn, and OneUp Google My Business

Founder Interviews: David Karandish of Jane.ai

A basic understanding of Kotlin and Node.js is needed to follow this tutorial. Just as the name implies, the aim of this article is to show the realtime movement of a marker on a map. This feature is common in location tracking applications. We see taxi apps and food ordering apps making use of features like this. Google provides an extremely easy map API, which we will take advantage of, while the realtime functionalities will be taken care of by Pusher. What we will build We will build an application that will receive coordinates from the server based on the initial coordinates we inject into it. When these coordinates are received, we update the map on our app. Requirements For this tutorial, we need the following: — version 3.0.1 or higher is recommended. Android studio and npm installed on your machine. Node JS A application. Pusher . Google Maps API key An Android device with Google Play Services installed. Building our server We will build our server using Node JS. The server will generate random coordinates for us. To start with, create a new folder. Inside it, create a new file named and paste this: package.json {"main": "index.js","dependencies": {"body-parser": "^1.16.0","express": "^4.14.1","pusher": "^1.5.1"}} Next, create file called in the root directory and paste this: index.js // Load the required librarieslet Pusher = require('pusher');let express = require('express');let bodyParser = require('body-parser'); // initialize express and pusherlet app = express();let pusher = new Pusher(require('./config.js')); // Middlewaresapp.use(bodyParser.json());app.use(bodyParser.urlencoded({ extended: false })); // Generates 20 simulated GPS coords and sends to Pusherapp.post('/simulate', (req, res, next) => {let loopCount = 0let operator  = 0.001000let longitude = parseFloat(req.body.longitude)let latitude  = parseFloat(req.body.latitude) let sendToPusher = setInterval(() => {  
    loopCount++;

    // Calculate new coordinates and round to 6 decimal places...  
    longitude = parseFloat((longitude + operator).toFixed(7))  
    latitude  = parseFloat((latitude - operator).toFixed(7))

    // Send to pusher  
    pusher.trigger('my-channel', 'new-values', {longitude, latitude})

    if (loopCount === 20) {  
        clearInterval(sendToPusher)  
    }  
}, 2000);

res.json({success: 200}) }) // Indexapp.get('/', (req, res) => res.json("It works!")); // Serve appapp.listen(4000, _ => console.log('App listening on port 4000!')); The code above is an Express application. In the route, we are simulating longitude and latitude values and then sending them to Pusher. These will then be picked by our application. /simulate 💡 The longitude and latitude values will typically be obtained from the device being tracked in a real-life scenario. Finally, we will create the configuration file, named . Paste this snippet there: config.js module.exports = {appId: 'PUSHER_APP_ID',key: 'PUSHER_APP_KEY',secret: 'PUSHER_APP_SECRET',cluster: 'PUSHER_APP_CLUSTER',}; Replace the values there with the keys from your Pusher dashboard. Then install the modules needed by our server by running this command in the root directory: $ npm install Our server should be up and running on port . 4000 Building our realtime map in Android Studio Create a new Android project Open Android studio and create a new project. Enter your application details, include Kotlin support, choose a minimum SDK (this should not be less than API 14), choose an Empty Activity, and finish the process. Here is a quick GIF of the process: Adding app dependencies This demo has several dependencies. We need the Pusher dependency for realtime functionality, the Google Maps API for easy integration of maps into our app, and Retrofit to access our server with ease. Open your app-module file and paste the following dependencies: build.gradle // Pusher dependencyimplementation 'com.pusher:pusher-java-client:1.5.0' // Google maps APIimplementation 'com.google.android.gms:play-services-maps:11.8.0' // Retrofit dependenciesimplementation 'com.squareup.retrofit2:retrofit:2.3.0'implementation 'com.squareup.retrofit2:converter-scalars:2.3.0' Sync your Gradle files so that the libraries can be downloaded and made available. Building our layout Open the and paste this: activity_main.xml <?xml version="1.0" encoding="utf-8"?><FrameLayout xmlns:android=" "xmlns:tools=" "android:layout_width="match_parent"android:layout_height="match_parent"android:orientation="vertical"><fragment xmlns:android=" "xmlns:tools=" "android:layout_marginTop="50dp"android:id="@+id/map"android:name="com.google.android.gms.maps.SupportMapFragment"android:layout_width="match_parent"android:layout_height="match_parent"tools:context="com.example.mapwithmarker.MapsMarkerActivity" /><Buttonandroid:id="@+id/simulateButton"android:layout_width="match_parent"android:layout_height="wrap_content"android:text="Simulate" /></FrameLayout> http://schemas.android.com/apk/res/android http://schemas.android.com/tools http://schemas.android.com/apk/res/android http://schemas.android.com/tools In the snippet above, we have a fragment which will hold our map and a button. Setting up Google Maps API key It is expected that at this point, you have obtained your API key. You can follow the steps to get it. We now want to configure the application with our key. Open your file and paste it in. This is located at : here strings.xml name-of-project/app/src/main/res/values <resources><string name="google_maps_key">GOOGLE_MAPS_KEY</string></resources> ⚠️ Replace the _GOOGLE_MAPS_KEY_ placeholder with the actual key from Google. This file contains all strings used during the development of the application. All raw strings within the app are kept here. It is required when there is a need to translate your app into multiple languages. Next, open the file and paste these under the tag: AndroidManifest.xml <application> <meta-dataandroid:name="com.google.android.gms.version"android:value=" ion" /><meta-dataandroid:name="com.google.android.geo.API_KEY"android:value=" " /> @integer/google_play_services_vers @string/google_maps_key With this, our app knows how and where to fetch our key. Setting up Retrofit We already have Retrofit available as a dependency, but we need two more things — an interface to show endpoints/routes to be accessed and our retrofit object. First create a new Kotlin file name and paste this: ApiInterface.kt import okhttp3.RequestBodyimport retrofit2.Callimport retrofit2.http.Bodyimport retrofit2.http.POSTinterface ApiInterface { ("/simulate")fun sendCoordinates( coordinates: RequestBody): Call<String>} @POST @Body Since we will make just one request in this demo, we will limit the scope of our Retrofit object to the class. This means we will create a function within a class for it. Paste this function into the class: MainActivity.kt fun getRetrofitObject(): ApiInterface {val httpClient = OkHttpClient.Builder()val builder = Retrofit.Builder().baseUrl(" ").addConverterFactory(ScalarsConverterFactory.create())val retrofit = builder.client(httpClient.build()).build()return retrofit.create(ApiInterface::class.java)} http://10.0.3.2:4000/ I used a Genymotion emulator and the recognized localhost address for it is . 10.0.3.2 Add the internet permission to the file: AndroidManifest.xml <uses-permission android:name="android.permission.INTERNET"/> Configuring our map and getting realtime updates For us to initialize and use the map, our the class must implement the interface and override the method. We also need to setup Pusher to listen to events and receive the simulated coordinates in realtime. Open your and paste this: MainActivity.kt OnMapReadyCallback onMapReady MainActivity.kt import android.support.v7.app.AppCompatActivityimport android.os.Bundleimport android.util.Logimport com.google.android.gms.maps.*import com.google.android.gms.maps.model.MarkerOptionsimport com.google.android.gms.maps.model.LatLngimport com.pusher.client.Pusherimport com.pusher.client.PusherOptionsimport kotlinx.android.synthetic.main.activity_main.*import okhttp3.MediaTypeimport okhttp3.OkHttpClientimport org.json.JSONObjectimport retrofit2.Callimport retrofit2.Callbackimport retrofit2.Responseimport retrofit2.Retrofitimport retrofit2.converter.scalars.ScalarsConverterFactoryimport okhttp3.RequestBodyimport com.google.android.gms.maps.model.CameraPositionimport com.google.android.gms.maps.model.Marker class MainActivity : AppCompatActivity(), OnMapReadyCallback { private lateinit var markerOptions:MarkerOptions

private lateinit var marker:Marker

private lateinit var cameraPosition:CameraPosition

var defaultLongitude = -122.088426

var defaultLatitude  = 37.388064

lateinit var googleMap:GoogleMap

lateinit var pusher:Pusher

override fun onCreate(savedInstanceState: Bundle?) {  
    super.onCreate(savedInstanceState)

    setContentView(R.layout.activity\_main)

    markerOptions = MarkerOptions()

    val latLng = LatLng(defaultLatitude,defaultLongitude)

    markerOptions.position(latLng)

    cameraPosition = CameraPosition.Builder()  
            .target(latLng)  
            .zoom(17f).build()  
}

override fun onMapReady(googleMap: GoogleMap?) {  
    this.googleMap = googleMap!!

    marker = googleMap.addMarker(markerOptions)  
    googleMap.animateCamera(CameraUpdateFactory.newCameraPosition(cameraPosition))  
} } We first created some class variables to hold our initial coordinates and other map utilities like the camera position and the marker position. We initialized them in the function. Next, we added a click listener to the simulate button. onCreate The next thing to do is still in the class. In the method, paste this: MainActivity.kt onCreate simulateButton.setOnClickListener {callServerToSimulate()} When the button is clicked, it calls the function. Create a function within the class like this: callServerToSimulate callServerToSimulate private fun callServerToSimulate() {val jsonObject = JSONObject()jsonObject.put("latitude",defaultLatitude)jsonObject.put("longitude",defaultLongitude)val body = RequestBody.create(MediaType.parse("application/json"),jsonObject.toString())getRetrofitObject().sendCoordinates(body).enqueue(object:Callback<String>{override fun onResponse(call: Call<String>?, response: Response<String>?) {Log.d("TAG",response!!.body().toString())}override fun onFailure(call: Call<String>?, t: Throwable?) {Log.d("TAG",t!!.message)}})} In this function, we sent our initial coordinates to our server. The server then generates twenty coordinates similar to the initial ones sent and uses Pusher to send them to channel , firing the event. my-channel new-values Next, we create and initialize a object with the view ID of the map: SupportMapFragment val mapFragment = supportFragmentManager.findFragmentById(R.id.map)  as  SupportMapFragmentmapFragment.getMapAsync(this)setupPusher() Next add the the function to the class and it should looks like this: setupPusher private fun setupPusher() {val options = PusherOptions()options.setCluster(PUSHER_CLUSTER)pusher = Pusher(PUSHER_API_KEY, options) val channel = pusher.subscribe("my-channel")

channel.bind("new-values") { channelName, eventName, data ->  
    val jsonObject = JSONObject(data)  
    val lat:Double = jsonObject.getString("latitude").toDouble()  
    val lon:Double =  jsonObject.getString("longitude").toDouble()  
      
    runOnUiThread {  
        val newLatLng = LatLng(lat, lon)  
        marker.position = newLatLng  
        cameraPosition = CameraPosition.Builder()  
                .target(newLatLng)  
                .zoom(17f).build()  
        googleMap.animateCamera(CameraUpdateFactory.newCameraPosition(cameraPosition))  
    }  
} } We initialized Pusher here and listened for coordinate updates. When we receive any update, we update our marker and move the camera view towards the new point. You are expected to replace the Pusher parameters with the keys and details found on your Pusher dashboard. We then call the disconnect and connect functions in the and functions respectively in the class. These functions are inherited from the parent class : onPause onResume AppCompatActivity override fun onResume() {super.onResume()pusher.connect()} override fun onPause() {super.onPause()pusher.disconnect()} Conclusion We have been able to leverage the power of Pusher, Kotlin and Google Maps API to create a realtime location tracking app. Hopefully you have picked up a thing or two from the tutorial and can use the knowledge to build beautiful realtime apps using Pusher and Kotlin. This post first appeared on the blog. Pusher

Build a realtime map using Kotlin

Recently I made a that requires user accounts. I learned quite a bit about setting up authentication with Firebase on the client-side and using it on the server-side to protected API routes with a middleware pattern similar to Express.js. This post is a recap of what I learned based on this project for future reference. You can find the code for this project on GitHub . small web app here Authentication - Client Side Initialization Setting up Firebase is easy. You create a project and enable the sign-in providers you plan to use, along with authorized domains. Grab the credentials from Project Settings in the Firebase console, and we can initialize the Firebase SDK on the client-side like this. here firebase ; ; ; clientCredentials = { : process.env.NEXT_PUBLIC_FIREBASE_API_KEY, : process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN, : process.env.NEXT_PUBLIC_FIREBASE_DATABASE_URL, : process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID, : process.env.NEXT_PUBLIC_FIREBASE_APP_ID,
}; (!firebase.apps.length) {
  firebase.initializeApp(clientCredentials);
} firebase //lib/firebase.js import from 'firebase/app' import 'firebase/auth' import 'firebase/firestore' const apiKey authDomain databaseURL projectId appId if export default (See file and folder structure in the actual project) here React Hooks and Context Provider Since the user's authentication status is a "global" state, we can avoid recursively passing it as a prop through many layers of components by using . Context To do this, we need a context Provider and a context Consumer. A Provider comes with a Context created by createContext(). The value prop we pass to the Provider will be accessible by its children. authContext = createContext(); { auth = ; //lib/auth.js const export ( ) function AuthProvider { children } const /* something we'll fill in later */ return {children} ;
} < = > authContext.Provider value {auth} </ > authContext.Provider For the descendant components to use the value, i.e., consume the Context, we can use Context.Consumer, or more conveniently, the useContext . hook useAuth = { useContext(authContext);
}; SomeComponent = { { user, loading } = useAuth(); } //lib/auth.js export const => () return //components/SomeComponent.js const => () const // later we can use the object user to determine authentication status // ... In Next.js, the AuthProvider we implemented above can be inserted in the _app.js so all the pages in the app can use it. See . here Implementation Details of `AuthProvider` In the AuthProvider skeleton above, we passed an auth object as the value prop, and this is the key thing that all the consumers consume. Now we need to figure out what we need to implement this auth object. The key thing auth need to achieve is subscribing to the changes in the user's login status (and associated user info). These changes can be triggered through the Firebase SDK, specifically the sign-in / sign-out functions such as firebase.auth.GoogleAuthProvider() and authentication state observer function firebase.auth().onAuthStateChanged(). So, our minimal implementation could be the following, mainly pay attention to the new getAuth function. We definitely need to return something from getAuth and that'll be the auth object used by AuthProvider. To do this, we implement the handleUser function to update the state user as follows React, { useState, useEffect, useContext, createContext } firebase authContext = createContext() { auth = getAuth() //lib/auth.js import from 'react' import from './firebase' const export ( ) function AuthProvider { children } const return {children} }

export const useAuth = () => {
  return useContext(authContext)
}

function getAuth() {
  const [user, setUser] = useState(null)
  const handleUser = (user) => {
    if(user){
      setUser(user)
    }
  }

  useEffect(() => {
    const unsubscribe = firebase.auth().onAuthStateChanged(handleUser);
    return () => unsubscribe();
  }, []);
  
  /* TBA: some log in and log out function that will also call handleUser */
  
  return {user}
} < = > authContext.Provider value {auth} </ > authContext.Provider Since we are calling other React Hooks, e.g. userEffect,  getAuth needs to be either a React functional component or a custom hook in order to follow the . Since we are not rendering anything, just returning some info,  getAuth is a custom hook and we should thus rename it to something like useFirebaseAuth (i.e the custom hook's name should always start with use, per ). The main function userFirebaseAuth provides us is to share the user state between components. Actually, across all the components since we used a Context Provider in _app.js. rules here note here Below is a fuller implementation of userFirebaseAuth. There are quite a few things we added here: Exposing sign-in and sign-out logic so that context consumers can use them. Since they would trigger changes in user state similarly to firebase.auth().onAuthStateChanged, it is better to put them here. We actually need to change firebase.auth().onAuthStateChanged to firebase.auth().onIdTokenChanged to capture the token refresh events and refresh the user state accordingly with the new access token. Adding some formatting to make the user object only contains our app's necessary info and not everything that Firebase returns. Add redirect to send user to the right pages after sign-in or sign-out. React, { useState, useEffect, useContext, createContext } ; Router ; firebase ; { createUser } ; authContext = createContext(); { auth = useFirebaseAuth(); import from 'react' import from 'next/router' import from './firebase' import from './db' const export ( ) function AuthProvider { children } const return {children} ;
}

export const useAuth = () => {
  return useContext(authContext);
};

function useFirebaseAuth() {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  const handleUser = async (rawUser) => {
    if (rawUser) {
      const user = await formatUser(rawUser);
      const { token, ...userWithoutToken } = user;

      createUser(user.uid, userWithoutToken);
      setUser(user);

      setLoading(false);
      return user;
    } else {
      setUser(false);
      setLoading(false);
      return false;
    }
  };
  
  const signinWithGoogle = (redirect) => {
    setLoading(true);
    return firebase
      .auth()
      .signInWithPopup(new firebase.auth.GoogleAuthProvider())
      .then((response) => {
        handleUser(response.user);

        if (redirect) {
          Router.push(redirect);
        }
      });
  };

  const signout = () => {
    return firebase
      .auth()
      .signOut()
      .then(() => handleUser(false));
  };

  useEffect(() => {
    const unsubscribe = firebase.auth().onIdTokenChanged(handleUser);
    return () => unsubscribe();
  }, []);

  return {
    user,
    loading,
    signinWithGoogle,
    signout,
  };
}

const formatUser = async (user) => {
  return {
    uid: user.uid,
    email: user.email,
    name: user.displayName,
    provider: user.providerData[0].providerId,
    photoUrl: user.photoURL,
  };
}; < = > authContext.Provider value {auth} </ > authContext.Provider Authorization - Server Side The other use case we need with Firebase authentication is to ensure users have proper access to server-side resources, i.e., specific API routes will be only accessible if certain access criteria is met. I guess this called authorization. An example would be, for /api/users/[uid] route, we would only return results the user requesting their own info. Firestore Security Rules One pattern to manage access to backend resources (mostly database access) is to use Firestore and Firebase authentication together and use Firestore's to enforce access permissions. security rules For example, in the example above, to limit access to user info, on the client-side, we attempt to retrieve the user record as usual { doc = firestore.collection( ).doc(uid).get(); user = { : doc.id, ...doc.data() }; user;
} export async ( ) function getUser uid const await 'users' const id return But we define the following set of security rules to only allow read/write when the user's uid matches the document's uid. rules_version = ;
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{uid} {
      allow read, : isUser(uid);
    }
  }
} { isSignedIn() && request.auth.uid == uid;
} { request.auth.uid != ;
} '2' write if ( ) function isUser uid return ( ) function isSignedIn return null You can actually do a lot with this setup. For example, in order to determine access to a document, you can do some extra queries on other collections and documents. Here are the I used, which involved a bit of that. security rules With this client-side setup and security rules, there are downsides. Mainly: We are defining access using this security rule syntax, which is less flexible than just writing arbitrary code on the server-side. Firestore also limits the number of queries you can do to verify the access permission on each request. This may limit how complex your permission scheme can be. Some of the database operations can be very heavy, such as recursively deleting a large document collection, and should only be done on the server-side. (See Firestore's documentation for more details.) here Testing security rules require extra work. (Firebase does have a friendly UI and simulator for this). Finally, it gets a little scattered that some database access logic lives on the client-side ( ) and some on the server-side ( ). I probably should consolidate to the server-side. code pointer code pointer Using Firebase Admin on Server Side OK, now the more "classic" way of doing the authorization on the server-side. The general workflow is: The client-side code should send over an access token along with each request. The server-side code has an instance of firebase-admin, which can verify and decode the access token and extract user information, such as the uid of the user Based on that information, the server-side code can do more queries and apply more logic to figure out it should proceed or reject the request. (The firebase-admin will have privileged access to all Firebase resources and will ignore all the security rules, which are only relevant for client-side requests). This is how I initialized firebase-admin * admin ; (!admin.apps.length) {
  admin.initializeApp({ : admin.credential.cert({ : process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID, : process.env.FIREBASE_CLIENT_EMAIL, : process.env.FIREBASE_PRIVATE_KEY.replace( , ),
    }), : process.env.NEXT_PUBLIC_FIREBASE_DATABASE_URL,
  });
} firestore = admin.firestore(); auth = admin.auth(); { firestore, auth } //lib/firebase-admin.js import as from 'firebase-admin' if credential projectId clientEmail privateKey /\\n/g '\n' databaseURL const const export The documentation suggests generate a private key JSON file. The file contains many different fields, the three fields above: projectId, clientEmail, and privateKey seem to be enough to get it to work. here Now we can extract uid on each request and verify the user's access { auth } ; (req, res) => { (!req.headers.token) { res.status( ).json({ : });
  } { { uid } = auth.verifyIdToken(req.headers.token);
    req.uid = uid;
  } (error) { res.status( ).json({ : error.message });
  } } import from '@/lib/firebase-admin' export default async if return 401 error 'Please include id token' try const await catch return 401 error // more authorization checks based on uid // business logic Authentication Middleware for Next.js API Routes One small annoyance with the above is that as we have more API routes that need authentication, the code need to be repeated in these API routes functions. I find Next.js out of the box doesn't have as strong a support for server-side development. A couple of things from Express.js I wish Next.js have are: routers and . middleware In this scenario, making authentication work as a middleware would be convenient. Middleware is things you can plug into the request handling lifecycle; the middleware would enrich the request and/or the response objects and can terminate the request early if errors occur. It turned out to be pretty straightforward, we just need to create a wrapper for our normal handler function, and in the wrapper we can modify the req and res objects and return early if errors occur. Here is how I defined a withAuth middleware { auth } ; { (req, res) => { authHeader = req.headers.authorization; (!authHeader) { res.status( ).end( );
    } token = authHeader.split( )[ ]; decodedToken; {
      decodedToken = auth.verifyIdToken(token); (!decodedToken || !decodedToken.uid) res.status( ).end( );
      req.uid = decodedToken.uid;
    } (error) { .log(error.errorInfo); errorCode = error.errorInfo.code;
      error.status = ; (errorCode === ) {
        error.status = ;
      } res.status(error.status).json({ : errorCode });
    } handler(req, res);
  };
} import from '@/lib/firebase-admin' export ( ) function withAuth handler return async const if return 401 'Not authenticated. No Auth header' const ' ' 1 let try await if return 401 'Not authenticated' catch console const 401 if 'auth/internal-error' 500 //TODO handlle firebase admin errors in more detail return error return And this is how we can use it, notice instead of exporting handler we are exporting withAuth(handler) { withAuth } ; { getUserSites } ; handler = (req, res) => { { { sites } = getUserSites(req.uid); res.status( ).json({ sites });
  } (error) { .log(error); res.status( ).json({ : error.message });
  }
}; withAuth(handler); // get all sites of a user import from '@/lib/middlewares' import from '@/lib/db-admin' const async try const await return 200 catch console return 500 error export default Here are the relevant files on GitHub: and . middleware.js sites route That's all I learned about authentication on the client and server side with Next.js and Firebase. Overall it's a great developer experience and pretty painless to figure things out. Previously published at https://www.dingran.me/next-js-authentication/

Next.js: Firebase Authentication and Middleware for API Routes

Build a ride sharing iOS app with push notifications.

Deep link to your installed email clients We needed to display an list of help options to the user in multiple places in our app. and have handled this well in the past with producing an action sheet of installed email clients. Monzo Slack Here we are going to create a similar action sheet, which will show the users installed email clients on the phone, and give them the ability to open them from our app. For this we will need to do a few things, and I will walk you through the steps I took one by one. Find the code , along with a simple sample project. here Create the UI component At WeVat, we are trying to ‘componentise’ the application where ever we can, through the use of protocols. Shout out to and for their insightful articles on this subject. Matthijs Hollemans Natasha The Robot This part of functionality will be well suited into a ‘Presenter’ type component. I will show you how we achieve this: Create the Presenter protocol: Here we: 1) Define the UIAlertController we will be using for the action sheet 2) Define the setup function which will configure the action sheet. This will later be called from viewDidLoad Setup the action sheet In an extension on our protocol, we define the setup that is needed for the action sheet. Currently we will just setup the static elements, which is the title and the cancel button. Conform to the protocol in our view controller So now we have successfully setup the action sheet in a presenter class, ready to be shown from whichever view controller wants! Run the app and you should see an action sheet appear like this Empty Action Sheet Get a list of installed email clients To open another app on your device in iOS, you need to use . I will again break this into the below steps for clarity: iOS URL schemes Locate the URL scheme for the required apps Maybe my googling skills are not upto scratch, but this was the most time consuming part of the process. After searching the depths of the internet, I came across this which outlined lists of URL schemes for iOS apps (thank you !). reddit post /user/meefmaster We have decided to include the following email clients so far: Mail, Dispatch, Outlook, Gmail and Inbox. Identify which apps the user has installed There is an instance method on UIApplication which will test if the installed application can open a URL. This is perfect for our needs, so we can do this with the below code: Create actions to open these apps Now we can tell which of the email clients the user has installed on their device, we can go ahead and wire them into the action sheet actions! 1) Create UIAlertAction We can now create a safe method to create UIAlertActions to open the email apps the user has installed Note the warning for users targeting only iOS 10 & above : https://useyourloaf.com/blog/openurl-deprecated-in-ios10/ Add our actions to our ActionSheet if they exist Now try and run the app on your device (the iOS Simulator does not support openURL schemes for this). Boom! It doesn’t work. We need to first make sure of one more thing. You may see this message in your console: -canOpenURL: failed for URL: “googlegmail:///” — error: “This app is not allowed to query for scheme googlegmail:///” This is here because we need to explicitly tell our app which other apps we intend to access. 2) Add the the scheme to your info.plist We can do this through the beautiful thing that is the Info.plist file. Add a new key called LSApplicationQueriesSchemes as an array. Then you can enter your apps within the array. The Mail app doesn’t need to go in here, presumably because it is an Apple app. Your entry should look like the below. Info.plist If you are still seeing the message, ensure you actually have the app installed on your device 😉 Run and voila! You should see the actionsheet appear like below: Tap on an action and it should open the corresponding email application. Give it some context! Upon tapping on a mail option, you will discover that it will open the email client. In our use case, this was tapped when the user wants to email our help address, therefore the subject and recipient will always be the same. As you might have noticed if you saw some of the iOS URL Schemes, you can pass query parameters in the app through the link. We want to pass these in when we build the Alert Actions, so I have refactored this out to do so, each email in their own functions. One last thing we will need to do is URL encode the subject line before we pass it into the URL. We can do this by calling on the string. subjectString?.addingPercentEncoding(withAllowedCharacters:NSCharacterSet.urlQueryAllowed) Last last thing… There is always the possibility to one of our users doesn’t have one of the listed apps installed, or indeed just accesses their emails through a web browser. In this case, we can simply give them the option of opening in Safari. We can refactor our code slightly to make this work by populating our Alert Actions into a temporary array, and then populate our ActionSheet with Safari only if this array is empty. And refactor our setup function to look like this: Wrap up So we’re pretty much done here. You will now be able to reuse this logic whenever you want to add email options to your users. Just conform to your new presenter protocol! If you wanted to reuse this presenting logic, for different types of apps than email, then you just need to find the URL schemes you need and repeat the process. Simple! Thanks for reading this far. Please do comment if you have any thoughts around this area, or think it could be improved!

Stories, News & Mentions about ADDINGAPP

Addingapp’s Stories on HackerNoon