㈠ Native App与Web App
Native App开发
即原生APP开发模式，利用iOS、Android开发平台官方提供的开发工具进行APP的开发。
特点：
（1）功能多：可以访问手机的所有功能，如定位、GPS、摄像头等。
（2）速度快、性能高、整体用户体验好。
（3）离线使用：若App内部涉及到大量的视频、图片等信息，在流量有限的情况下，需要用户将这些文件保存到本地，以供离线使用。并且再次打开时，不需要重新加载，访问速度快。
（4）App质量及安全性好。
（5）Native App开发非常费时费力，不同的版本需要单独开发。
Web App开发
Web App开发主要依靠H5框架开发，类似于网页，而不是单独的程序。
特点：
（1）在浏览器上运行，项目独立。
（2）单一版本开发，开发周期短、难度小。
（3）Web APP的功能有限，不能调用手机功能。
（4）性能需要进行检验，不如原生App。
（5）每次打开都需要重新加载，访问速度慢，无法离线浏览。
（6）技术不成熟，质量及安全性无法得到保障。
㈡ ios怎么和h5界面实现交互
实现ios怎么和h5界面实现交互比较常见的方法就是使用OC中自带的UIWebView类，来实现加载H5网页界面。
创建webView，遵循代理并实现其方法：
1.--webViewDidStartLoad
在该方法中可以让“小菊花”即UIActivityIndicatorView开转
2.--webViewDidFinishLoad
小菊花停止转动，并从界面中移除
3.--webViewDidFailLoadWithError
做相关操作，打印错误原因，重载等
㈢ Hybrid App开发中，web端与native端几种常见的通信场景
本篇文章，我们主要叙述一下Hybrid App中常见的几种通讯场景，包括 注册 、 登录 、 支付 、 登录状态的保持 以及 退出 。由于我在前面的文章中已经有过对web端和native之间通信方式的讲解，所以本篇文章主要是以使用为主。如果您还不了解web端和原生端的通信方式，请查看我的这篇文章 《Hybird App中 Android 和 IOS 与网页之间的通信》 进行学习，了解基础非常重要。
Register.vue
1、注册按钮点击事件，针对不同的平台使用不同的逻辑。
2、调用android注册方法。需要在android端注册 register 方法，并返回是否通过校验的值（boolean）。
3、调用IOS注册方法。当然也需要在IOS原生端定义 register 方法，由于IOS中不能直接返回结果给web端，所以需要在web端的 window 对象中挂载一个回调方法 onRegisterCallback ,等IOS端完成处理后，执行该方法。
一定要注意，要在执行 window.webkit.messageHandlers.register.postMessage(userJson) 执行前将 注册回调方法onRegisterCallback 进行挂载。
4、注册回调方法
当我们完成了注册功能，其他的功能其实就是简单复制的过程了。话不多说，咱们码上见真情。
Login.vue
1、登录按钮点击事件
3、调用 android 登录验证
4、调用 ios 登录验证
5、接收登录验证结果
当然，在登录成功后，我们需要将用户通过 vuex 进行保存，这里就不细讲了。同时，在原生端也会将用户名进行保存。
在原生端启用webview加载完web端页面的后回去执行，我们挂载在web端 window 下面的方法 nativeFunctionUserLogin 方法，并将原生端保存的用户名发送给web端。web端再将用户保存在vuex中，如此，就实现了登录状态的保持。
App.vue
首先看一下支付页面。
1、支付点击事件
2、支付方式点击事件
1、退出登录按钮点击事件
2、调用 android 退出登录的方法
3、调用 android 退出登录的方法
4、退出登录的回调方法
㈣ 如何区别一个 App 是 Native App，Web App 还是 Hybrid app
nativeapp是一个原生程序，一般运行在机器操作系统上，有很强的交互，一般静态资源都是在本地的。浏览使用方便，体验度高。在实现上要么使用Objecttive-c和cocoaTouch Framework撰写IOS程序，要么选择java+Android Framework撰写android应用程序。
hybridapp是一个半原生程序，伪造了一个浏览器的apk/ipa原生程序，把地址写死了，然后里面运行了一个webapp。里面是WebView UI 。但是还是运行在机器的操作系统上，交互较弱，资源一般在本地或者网络都可以。浏览体验度次之。
webapp是生存在浏览器里的应用，所以只能运行在浏览器里，宿主是浏览器，不再是操作系统。
㈤ 如何选择Web APP与Native App原生开发模式的区别，APP开发模式比较
NativeApp开发
Native App开发即我们所称的传统APP开发模式（原生APP开发模式），该开发针对IOS、Android等不同的手机操作系统要采用不同的语言和框架进行开发，该模式通常是由“云服务器数据+APP应用客户端”两部份构成，APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。
WebApp开发
Web App开发即是一种框架型APP开发模式（HTML5 APP 框架开发模式），该开发具有跨平台的优势，该模式通常由“HTML5云网站+APP应用客户端”两部份构成，APP应用客户端只需安装应用的框架部份，而应用的数据则是每次打开APP的时候，去云端取数据呈现给手机用户。
原生APP开发及Web
APP开发模式的区别
Web
APP需开发“html5云网站”和“APP客户端”，昆明天度网络公司总结这类型APP应用呈现以下特点：
（1）每次打开APP，都要通过APP框架向云网站取UI及数据；
（2）手机用户无法上网则无法访问APP应用中的数据。
（3）框架型的APP无法调用手机终端的硬件设备（语音、摄像头、短信、GPS、蓝牙、重力感应等）
（4）框架型APP的访问速度受手机终端上网的限制，每次使用均会消耗一定的手机上网流量；
（5）框架型APP应用的安装包小巧，只包含框架文件，而大量的UI元素、数据内容刚存放在云端；
（6）APP用户每次都可以访问到实时的最新的云端数据；
（7）APP用户无须频繁更新APP应用，与云端实现的是实时数据交互；
适用企业：电子商务、金融、新闻资讯、企业集团需经常更新内容的APP应用。
Native
App（原生型APP）需要开发“云服务器数据中心”和“APP客户端”，昆明天度网络公司总结这类型的APP应用呈现以下特点：
（1）每次获取最新的APP功能，需要升级APP应用；
（2）原生型APP应用的安装包相对较大，包含UI元素、数据内容、逻辑框架；
（3）手机用户无法上网也可访问APP应用中以前下载的数据。
（4）原生型的APP可以调用手机终端的硬件设备（语音、摄像头、短信、GPS、蓝牙、重力感应等）
（5）APP应用更新新功能，涉及到每次要向各个应用商店进行提交审核。
适用企业：游戏、电子杂志、管理应用、物联网等无需经常更新程序框架的APP应用。
到底该如何选择Web
App和Native App开发模式
移动Web无所不在，移动Web是目前唯一的支持各种设备访问的平台，与桌面Web一样，移动Web支持各种标准的协议。移动Web也是唯一一个可供开发者发布移动应用的平台，它将各种移动交互与桌面任务有效地连接了起来；而开发Native
App可以充分利用设备的特性，而这一点往往是Web浏览器做不到的，所以对一个产品本身而言，Native App是最佳的选择。下面几节将讨论一下Native
App的一些主要功能。
什么时候应该选择Native
App
1.为应用收费
没有任何地方规定开发者不能对一个移动Web
App收取使用费，但是由于某些原因，人们常常认为不能或是不应该对一个Web App收取费用。由于历史原因，导致移动设备上付费服务遭遇两大阻力：
2.付款方式
在移动设备上输入信用卡号相当麻烦，而且在许多老式设备上也没有安全保障。一种典型的方式是，如果你需要对你的应用收费，你可以与运营商达成协议，让运营商代为为你的服务收费。这也意味着，你需要和多个运营商达成合作。这通常是首选的方法，因为许多手机用户可能根本就没有信用卡，比如青少年。
另一种方法是将用户的信用卡信息保存在一个安全的网站上。用户可以通过登录到该网站购买应用服务。这个过程不算特别理想，因为这意味着用户不能直接通过他们的移动设备购买服务了。
3.强制分成
移动运营商是会提成的。App无论是通过运营商还是通过移动设备发布，他们都为应用提供了一套收费机制。这些运营商和移动设备将会提取部分收益，然后将剩余的部分交给应用开发商，这也意味着，开发人员必须遵守他们的市场规则。适应运营商的市场规则通常是非常困难的，需要投入大量的人力资源。相比而言，移动设备的市场规则则简单许多，但是也存在不少的困难。
妨碍运营商和移动设备开发商利益的应用以及服务都将受到阻扰。过去，那些不靠运营商和移动设备开发商运作的网站如果收入过于显眼的话，都逃脱不了被关闭的命运，但是最近，这样的事情鲜少发生了。
如果你想为你的Native
App收费，那么你就必须接受这个现实——你必须遵守别人的市场规则，还得放弃部分收益。
4.开发游戏
如果你是想开发一个移动游戏（移动游戏是移动市场上最大的一块），那么你需要开发一个Native
App。游戏对资源的占用很大，并且需要使用许多设备API或平台API。虽然，现在有几款完全使用Web技术开发的游戏占有了一定的市场份额，但是和Native
App市场的占有情况相比，还是微不足道的。游戏用户对应用的视觉和操作效果要求很高。移动Web虽然提供了一些仿真体验，但还远远不能满足用户的需求。
在开发移动游戏时，你需要慎重考虑你的应用需要支持哪些平台。幸运的是，现在有许多工具能够帮助你将你的游戏推向多个平台，但是完成这些工作，还是需要花费大量的人力和物力。
5.使用定位功能
下一个功能就是定位功能，可以通过GPS或者是信号检测确定用户当前的位置信息。以前只能通过Native
App的APIs查看用户的位置信息，但现在大多数主流移动浏览器上都嵌入了W3C Geolocation
API。像iPhone或Android这样安装了WebKit的设备，或是配置了Opera或Mozilla浏览器的设备，都可以获取用户的位置信息。
我相信定位功能会为Web技术带来许多全新的应用。如果能够合理利用Web浏览器，Web开发商就能使用用户的位置信息和其他内容开发出更加有趣的应用。虽然这在技术上没有太大的困难，但却受到隐私保护条例的限制。我们将Web浏览器当做是用户进入World
Wide
Web的入口。加入定位功能，意味着在网站中引入了一些敏感信息，这有可能导致严重的后果。但是位置感知应用中显示的位置信息必须经过用户的授权，用户当然有权禁止应用发布自己的位置信息。
6.使用摄像头
摄像头可以为你的应用提供丰富的可能性。以往移动MMS（Multimedia Messaging
Service）被用于处理移动照片。换言之，你拍了一张照片后，需要使用MMS将它传送给一个服务器，服务器对照片做出相应的处理，并将处理完成的结果通知给你。这个过程是非常耗时的，而且相当复杂，也没有可靠性保障。
通过访问摄像头，Native
App开发者能够简化拍照的过程。用户可以直接在客户端对照片做一些简单的处理，只有在有需要的时候才将照片上传给服务器，而且是通过可靠的HTTP传输。W3C正在开发一个访问摄像头的API，但现在还没有将这部分工作正式整合到浏览器中。
在许多类型的移动Apps中，摄像头是非常有用的，比如快拍应用、短片拍摄应用等等，摄像头可以用来捕捉许多重要的瞬间。不久的将来，我们可以看到——只要通过摄像头拍摄某个标识，应用程序就能自动完成对标识上的语言转换工作——这个技术在日本已经开始流行起来了。
7.使用感应器
现在越来越来越多的移动设备上都新增了感应器功能，该装置可以感知设备的物理速度以及重力，并将感知的数据结果传送给设备。这个装置常被用来感应设置是否被翻转，应用根据接受到的信息自动调节画面的方向。
感应器可以用来帮助用户提升与设备交互时的真实感；大多数移动设备都是手持的，应用能够根据设备的方向调整内容画面，比如翻转屏幕，或是检测物理移动，并能据此猜测用户所处的环境。举一个简单的例子：比如用户正在走路，那么感应器能够检测到一个轻缓的移动或是速度，这时可以为用户提供一个大字体的用户界面，从而使得用户更容易看清屏幕上的内容。
然而，开发者也不能过分依赖感应器，因为感应器无法区分究竟哪些交互是有意的，而哪些是没有意义的。每个移动交互都需要通过“传输测试”。设计你的交互时必须考虑用户在一个拥挤的汽车或是火车上的场景。考虑一下如果用户正身处拥挤的地铁或是正在驾车时，你的应用能否正确处理用户摇晃移动设备的动作。通常，大多数开发者都没有考虑这些因素。确保为每个任务设计一个备用方案以处理特殊场景中的移动交互。
8.访问文件系统
如果你的应用需要将数据保存在本地，那么你需要开发一个Native
App。比如你要保存用户的地址簿、电话或E-mail信息，或是保存从其他设备上获取的数据。
访问文件系统常常会涉及到安全和用户隐私保护的问题。恶意应用程序可能会修改或是删除你的移动设备上的数据。一个携带病毒的应用程序可以利用移动设备上的关系网将病毒扩散到许多其他的手机上，在采用移动应用认证机制以前，这种事情是常常发生的。
另一方面，移动设备正变得越来越私人化，移动设备上保存了大量用户的个人信息，以及用户的朋友信息和商业信息。针对这些私人信息开发应用是一个不错的想法。但是这也存在一定的风险，使用保存在移动设备上的数据可以为用户提供更加有针对性的服务。
开发者必须谨记，只有在获得用户的授权后才能访问用户的私人数据。我们看到许多应用在没有得到用户授权的情况下使用了大量的用户私人数据，而被误认为是垃圾信息或是钓鱼应用，即使这些应用原本是在提供一些非常有用的服务。人们对你的应用的误解将会影响到你的服务的推广，如果运营商收到过多关于你的应用的投诉，那么你的服务可能将被终止，甚至会牵连其他的应用。
访问文件系统时至关重要的一点就是在没有获得用户授权的情况下，不要访问任何用户的私人数据。而这一点，往往被大多数应用忽略了。W3C正在为移动开发商开发相关的标准API，但目前该工作尚未完成。
9.离线用户
最后一个需要开发Native
App的理由就是，用户有可能是离线的或者无法接入移动网络。这在城市可能很少发生，即使是在农村，网络的覆盖也已经逐步普及了。但是短暂的网络连接中断还是时常发生的，你的应用程序应该考虑如何处理这种情景。
想想用户通常在什么时候，在哪里会使用你的App。如果是一个移动游戏，那么用户很可能在飞机上使用这个App。跟踪地图应用常在偏远且网络覆盖不佳的地方使用。移动旅游向导常在一个国外的网络中访问，往往需要支付漫游和国际网络费用。这时，应用程序最好能够为用户提供离线服务，保证用户在不接入网络的情况下，仍然能享受同等的服务。
现在支持HTML5的浏览器也能实现脱机访问功能，但对用户来说可能不太明显。随着越来越多的浏览器都开始支持脱机访问，应用需要明确地告诉用户网络连接中断时，他们仍然可以访问移动Web
Apps。
Native
Apps常常假设网络连接是可靠的。App通常只考虑了网络状况良好的情景，想当然地认为网络是封闭的，并且网速足够快。移动设备从网络良好的环境突然进入一个网络糟糕的环境并不少见。Native
Apps应该在网络状况最差的情况下测试。比如用户启动任务时可能还是全信号覆盖，而在任务结束时可能已经完全没有网络信号了。
用户在安装Native
Apps时，根本不会考虑是在线访问还是离线访问——他们期望的是不管在任何状况下，Native Apps都能正常工作。而这也是开发者的职责。
什么时候应该选择Web
App
只要你的应用程序不满足之前提到的Native App条件之一，那么你就没有必要开发一个Native
App，而应该选择开发一个Web App。正如文章之前提到的，我是一个Native App的拥护者，我认为Native
App有许多优秀的特质，并且具有很大的市场潜力，但是Web Apps是唯一一个经久不衰的移动内容、服务、应用开发平台。
Native
App并不能明显地为用户提供更好的服务；它反而会增加项目的成本，减少了应用发布的渠道，增加了App升级的复杂度，削弱了开发者对应用的控制和利润，并且可能会给设备带来麻烦。Native
App可以为开发者带来短期的效益，但这是有一定风险的，甚至可能会影响到移动市场的可持久发展。
移动Web App的优势在前文中已经提到过了。如果上一节提到的几点功能是促成你选择Native
App的唯一原因，那么如果能够在移动浏览器上屏蔽这些障碍，你是否还会坚持选择Native
App呢？Palm的webOS已经着手解决了上述的部分问题。他们基于WebKit构建了一个全移动操作系统，将手机变成了一个Web浏览器。所谓的“Native
Apps”实际上就是一个Web Apps。
PhoneGap也是一个类似的项目，这个开源项目用于帮助开发者在iPhone、Android以及BlackBerry设备上开发Native
Apps，并且能够模拟设备上的功能（如定位功能和文件系统）供Web
Apps调用。这些代码可以在各个设备的应用商店中发布并且出售，但是他们使用的通用代码和设计是可以共享的。由于开发的是一个Web
App，开发者可以为低端的移动浏览器开发一个简化版的应用。只用开发一次，就可以部署在多个平台上了，
对于那些有着丰富的移动开发经验的程序员来说，一提到“要开发一个功能丰富的应用”时，可能首先想到的就是Native
App。虽然在很多设备上，这一想法仍然适用，但是现在移动Web Apps上也提供了足够丰富的功能接口供开发者调用。这使得Web App不仅可以像Native
App一样被设计得功能丰富界面绚丽，而且还能在各个平台上迁移，甚至不用修改一行代码。
现在在移动设备开发中，移动Web
Apps的创新进入了前所未有的高潮时期。但更重要的是，这是有史以来第一次，移动设备开发商决定共同制定一个移动Web开发的标准，就像是桌面Web上的标准一样。不仅如此，那些支持移动Web
App创新功能的设备或是支持第三方浏览器的移动设备都受到消费者的欢迎。
㈥ Web App 和 Native App跟H5有什么不同该如何选择
移动互联网的快速推进，APP应用得到了响应性的普及，增长较明显的主要集中在创业型公司。同时，HTML（超文本标记语言）第五版的更新，也就是大家常说的H5，在移动端，由于其相对较低的开发成本及强大的跨平台运行能力，越来越多的信息型产品也开始选择这样轻量级的H5页面进行快速迭代，同时借用微信等平台快速触达用户。早期APP红利时期已过，使后面用户数量增加变得困难，应用市场推广APP的成本变得越来越高。对于还没有大量融资的产品，在产品布局时我们如何去选择尤为重要。Web App和 Native App跟H5我们应该如何选择呢？下面就为大家分享Web App 和 Native App跟H5的区别：
我们就从web相对App的优势\劣势来分析。
优势：
H5可跨平台使用，开发成本相对更低，一个产品经理+前端+设计+后台就能搞定；App则需适配iOS、安卓等不同平台进行设计和开发，至少需要iOS工程师+Android工程师+PM+前端+设计+后台，开发成本高出1/3甚至更多。
H5可随时上线就更新版本，适合快速迭代，且试错成本低。
一个功能做好了立马就能上线，一天更新几十次都毫无压力；App则需要用户主动下载更新，主流的就是iOS，Android、windows仨平台，不同平台运营推广的玩法还不一样，分发和运维成本很高。
而且一个版本的功能出来，虽然很快就能做出其中一部分让内部人员体验。但等我们全部做完了，可能已经过去一周了。然后提交给平台做审核，又要等一阵，再找个好日子发布，三周就过去了。同时，我们如果又做出了更多新的功能，优化了细节，再修复几个bug等等，用户却也只能再等几十天才能体验到。
H5可以轻量的触达用户，提供更便捷的服务。
相比在桌面上下一大堆App，在微信的入口或者浏览器上，用户只需点开链接就可以获取我们所提供的服务。有更高的使用时长及导流能力，基于公众号的运营和推广可以快速的触达用户。
劣势：
H5—>App的转化强依赖于浏览器，要把用户真正留存在自己的产品中需要进一步的转化；而APP可以内嵌H5，直接在应用内即可打开并与H5进行转化。
H5目前基本无法将数据存储在本地，依赖实时性数据，网络状态不好的时候卡到哭。
每当用户需要上传数据，比如输入，选择，传照片等，页面的延迟会影响使用的流畅性；而APP可以本地存储，运行速度更快，更省流量，可离线操作或者访问本地资源。
H5性能相对较低。
对于复杂的交互，比如3D特效，频繁的输入输出等等，即使实现了，在用户体验上也要减分。比如在Native App上，一个类似页面滑动切换的效果，基本不会感受到延迟，你手指只要开始滑动，页面就无缝的跟着滑动，但在Web上，大家应该都经常看微信里的各种H5的花哨分享页面吧，那滑动流畅吗？
对于Web App 和 Native App跟H5这三者最终该如何选择，我们还需要考虑，企业的具体产品需求，产品的核心功能，辅助功能，配合运营需求，应用场景等方面的影响。所有的产品都是有了场景才会有体验，针对体验才能有的放矢。再结合他们之间的的优劣情况，我们选择起来就显得比较简单了。
但是，有很多的公司和团队认为这两种模式都比较适合目前产品的使用范围，是否可以一起使用呢？微客达，一站式移动营销服务，整合Web App、Native App、H5、微信公众号等多种营销渠道，帮助商家快速低成本建立自己的掌上营销渠道，扩展生意辐射覆盖范围，沉淀新老顾客、促进二次销售、实现可持续经营。让您在移动互联网高速发展的今天，更快速的占领应用推广市场，从同行中脱颖而出。
㈦ 轻应用，Web App，Native App三者有什么区别
轻应用是什么
LAPP (Light App) 即轻应用是一种无需下载、即搜即用的全功能 App，既有媲美甚至超越native app的用户体验，又具备webapp的可被检索与智能分发的特性，将有效解决优质应用和服务与移动用户需求对接的问题。2013年 8月22日，网络在2013年网络世界大会上宣布推出“轻应用”，可实现无需下载，即搜即用和通过移动搜索能。
轻应用运行平台
轻应用在Android/iOS/WP7平台上都可以运行。
轻应用的特点
第一，无需下载，即搜即用。
以往，开发者付出高昂成本拉动用户下载应用，每隔十天半月还要推送更新版本，一不小心就遭用户卸载。例如，一款名叫多趣的旅游类应用，针对不同城市、不同景点有500多款应用，下载和更新成本成为横亘在开发者和用户间的高槛。通过轻应用，搜索“上海导览”、“周庄导览”的用户需求都可以直接调起多趣，开发者后端的每一处更新在前端都自动呈现，无需骚扰用户。
第二，破壳检索，智能分发。
开发者开发的应用不再是信息孤岛，里面的内容都可以被索引，这跟原生应用形成明显的差别。在应用商店里，只有用户输入明确的App名称，例如“嘀嘀打车”，这个应用才能够被分发。而现在，移动搜索中自然表达的所有与打车有关的需求，比如“我要打车”、“从国贸到雍和宫”等，都将导向开发者开发的打车类应用，大大增加应用的曝光量和使用率，从源头解决分发难题。
第三，功能强大，全能体验。
轻应用能够帮应用调起语音、摄像头、定位、存储等手机本地或云端的多种能力，让应用的功能更强大。以好大夫在线轻应用为例，开发者不仅可以设置语音交流模块，还可以调起本地摄像头帮助用户拍摄化验单或患处，从而提供和Native App相同甚至更好的体验。
第四，订阅推送，沉淀用户。
轻应用不仅支持用户搜索时实现调用，还支持用户主动订阅。如果用户有订阅需求并添加应用，相关开发者就能够将用户沉淀下来，并对用户进行持续、精准的信息和服务推送。例如，很多视频类应用的用户有追剧的需求，网络支持用户订阅的功能，只要用户订阅了应用，每当有新剧更新，开发者都可以第一时间通知用户，增强粘性，从而与用户建立起更加稳固牢靠的关系
㈧ iOS APP与H5交互的三种方法
这种方法是利用拦截webView响应的url，对url进行处理，同时把需要执行的方法名和参数都放入url中，实现app和H5之前的方法交互：
这个属性是WKWebView才有的属性，主要是通过WKScriptMessageHandler的代理方法 - (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message 进行交互。
注意：
这两个方法是成对出现的，每次调用了add就必须调用remove。
1.建立 WebViewJavaScriptBridge 和 WebView 之间的关系。
_jsBridge = [WebViewJavascriptBridge bridgeForWebView:_webView];
2.方法调用
1)oc调js方法（通过data可以传值，通过 response可以接受js那边的返回值 ）
2)js调oc方法（可以通过data给oc方法传值，使用responseCallback将值再返回给js）
最后：iOS调用H5方法
UIWebView： NSString *result = [webView :@"javascript:add(3,5);"];
WKWebView: [self.webView evaluateJavaScript:@"show()" completionHandler:^(id _Nullable response, NSError * _Nullable error) { //TODO }];