首页 文章

共享混合移动应用和桌面Web应用的代码

提问于
浏览
3

我想构建一个全新的应用程序,应该作为混合移动应用程序和桌面Web应用程序进行部署 .

大多数情况下,两个应用程序的逻辑和用户界面非常相似 . 除了一些差异:

  • 移动设备的屏幕尺寸优化(例如,移动设备中的隐藏侧边菜单与桌面设备中的扩展边菜单)

  • 手机中的触控手势(3DTouch)与桌面中的悬停功能

  • 触摸移动设备中某些元素的反馈

  • 移动中的页面导航与桌面中的路由导航

我想过将angular-material组件用于桌面,Ionic组件和导航用于移动设备,因为它们都 Build 在角度之上 .

当然,我的目标是尽可能多地共享代码,逻辑以及UI容器组件 .

因此,我尝试在为桌面UI,移动UI,共享UI和逻辑创建单独的Angular模块时考虑构建项目的好方法:

一种选择是为两个应用程序提供一个核心模块,导入逻辑和共享UI模块 . 然后在为每个平台构建时在特定平台UI模块之间切换 . 在此选项中,特定于平台的UI组件将具有相同的 selector@Input ,但它们的呈现UI会有所不同 .

第二个选项是为每个将导入逻辑模块和共享UI组件模块的平台应用程序提供单独的核心模块 .

也许有人有这样做的经验,可以分享他对涵盖所有这些的最佳项目结构的看法?

或者我建议哪个项目结构更好?

3 回答

  • 1

    根据我的经验,有效的是以下内容

    • 使用框架的特定"command line tools"(Angular CLI,Ionic CLI,NativeScript CLI)在单独的目录中创建具有单独文件结构的2个单独的'Front End'项目 .

    • 创建一个包含要由'front end'项目共享的公共模块的公共项目

    • 从代码存储库导入共享模块到'front end'项目(例如,在名为'shared'的目录下) - 确保将前端项目与'shared'项目的相同通用版本保持对齐

    真正的技巧是设置“共享”模块的边界,以便在不增加代码复杂性的情况下最大化重用(例如,通过在'共享'代码中检查环境 - 我避免使用环境变量来定义是否代码以Ionic或Angular运行,并根据该变量做出决定 .

    对我来说,经验法则是“前端”项目定义所有组件(即组件不共享) .

    组件具有非常浅的逻辑,通常类似于以下内容

    • 他们在 constructor 中定义他们使用的 services
      _109_在 ngOnInit() 方法中,他们订阅 services 方法返回的感兴趣的Observables - 订阅逻辑填充包含视图中显示的数据的变量
      _109_在 ngOnDestroy() 中取消订阅订阅

    • 组件定义管理前端事件的方法 - 此类方法通常调用共享服务上的方法

    编码时会出现正确的设计 . 我的意思是,一旦你 Build 了基本结构(即'前端'项目和'共享'项目),你就开始为一个前端编码(例如浏览器的Angular) . 一些决策很容易采取(例如,查询后端的所有逻辑通常都是共享的) . 其他一些决定更棘手,而且越接近前端表面的逻辑就越正确 . 一旦你看到组件中的逻辑变得越来越厚,那么你就开始想知道是否有值得分享的东西,因为对于另一个'前端'也许是常见的(让我们说Ionic) . 如果是这种情况,那么您重构,将代码移动到“共享”服务 .

    还要记住通过测试充分保护“共享”服务 .

    我希望它有所帮助

  • 5

    我也想知道如何做到这一点,我想出了一个非常聪明的解决方案(我使用的是NativeScript而不是Ionic) .

    你想要做的是在共享应用程序的业务逻辑时有两个开发环境(在导入方面略有不同等) . 虽然模板和一些样式是不同的 .

    实现此目的的一种方法是使用NativeScript CLI环境,然后在同一个环境中实现自己的webpack解决方案将开发Web应用程序的项目 . 使用带有NativeScript的Angular CLI实际上并不是那么好用,因为它们没有相同的项目结构 .

    然后我会设置两个环境变量 nativeweb . 然后我在我的打字稿文件中使用这两个来决定要导入什么以及使用什么代码 . 如果您只需要在文件中进行小调整,则可以将其与简单的if语句一起使用,但如果需要更改整个组件,则可以通过检查这些环境变量来切换整个文件 .

    关于模板和样式,您可以执行类似 name.component.native.htmlname.component.web.html 的操作,并使用与您的环境变量匹配的模板和样式 . 样式文件也是如此 .

    根据项目的大小,我认为这是一种非常易于管理的代码共享方式,无需单独管理2个项目 .

    我不是说这是正确的做法,但这是一种方式,我认为如果做得好,它可以很好地工作 .

    希望这在某些方面有所帮助 .

  • 1

相关问题